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TRENDS, THE AERONAUTICAL POST-TEST DATABASE SYSTEM 

Section I 

SUMMARY AND INTRODUCTION 


1 . 0 SUMMARY 

This report, describes TRENDS, an engineering database operating system 
developed by NASA to snppoLt rotorcraft flight tests. The history, 
concept, structure, usage, and features of the system are discussed. 
The purpose of this report is not to give instruction in the use o 
TRENDS (user manuals aie available for that purpose), but rather to 
document the system's capabilities, structure, features and reasons 
for being. The report shows that this system is able to support most 
aeronautical database test and analysis requirements including rotor- 
craft, fixed-wing aircraft., wind tunnel data, and simulation. 


1.1 INTRODUCTION 

TRENDS is an interactive Database Operating System developed by NASA 
to support rot ore raft research studies for NASA and for other govern- 
ment and nongovernment agencies. TRENDS offers a major breakthrough 
as an engineering database management system for rotorcraft research 
groups, because it can service both project management and engineering 
personnel thrrugh the use of both narrative and numerical data access 
and analysis. TRENDS could be considered as the LOTUS 1-2-3 for the 
aeronautical engineer who would like to do research and data analysis 
on rotorcraft. The system is fast, powerful, robust, and user-friendly, 
and has a multidisciplined user interface which allows the user to 
easily access and plot the data. 

This report is written primarily for someone considering TRENDS as a 
solution to the problem of storing and accessing engineering test data. 
This does not exclude those interested users or database managers who 
are already using TRENDS. The report attempts *o describe what TRENDS 
is and what it can do. TRENDS offers the Database Manager a database 
operating system which may fully meet his needs or may serve as the 
basis for one which could be developed with only minor modifications. 

The acronym TRENDS was derived from Tilt Rotor Engineer ing Database 
System because the system was originally developed (beginning about 
1982) to support flight testing of the XV-15 tilt-rotor aircraft. 

The system has been extended to support flight and wind tunnel tests 
of other rotcrcraft, but the name is still appropriate to the system’s 
function and has been retained. Before TRENDS, NASA engineers had only 
limited capabilities for displaying XV-15 data, and could not. cope with 
the large volume of test. data. TRENDS was developed to meet the needs 
of the engineers and coordinate the data. Appendix A contains a 
chronology of TRENDS’ development,. 
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1 . 1.1 


Users 


TRENDS is primarily htii 1 1 as a tool for the nonprogramming aeronaut- 
ical engineer, but it is also used by individuals of other disciplines 
with or without computer backgrounds. The system supports a wide var- 
iety of engineering disciplines from rotoi craft performance and hand- 
ling qualities, aeroelas tics , dynamics, flight control, and loads to 
tilt- rotor transitions and simulations. Narrative data complement the 
numerical data, identifying data items and databased flight segments. 

The system is designed to provide all of the project information a user 
needs without having to contact the flight-test engineer. Users can 
access any of the multiple TRENDS databases with the same software, 
as shown in figure 1.1. TRENDS currently runs on a VAX computer at Ames 
hence, it has all of the advantages of the DEC/VMS operating system, 
including full networking and remote user support. 

New 4t h- level programming languages can nowadays provide general 
capabilities for the creation of computerized databases and displays, 
but in spite of their generality, they fail to provide what is 
needed by engineers -- a fully pre-defined engineering interface to 
the data. These new languages stiii require the research engineer to 
configure software calls to obtain the data displays he wants, thereby 
providing user flexibility, but also requiring him to be a programmer 
and systems designer. The aeronautical engineer who is interested in 
viewing and analyzing test data is seldom interested in programming. 
TRENDS was developed to provide the user with a complete system without 
requiring him to write software or to locate and mount data tapes. 

1.1.2 Features 

TRENDS has been configured to be a complete database system which 
serves a variety of users. Among the features which make TRENDS 
useful are: 

1. Capabilities for multiple users and multiple databases. 

2. A flexible, prompt-driven interface with easy defaults. 

3. Capabilities for searching and plotting statistical data. 

4. Narrative storage and searching features. 

5. Support for many different graphics devices. 

6. Flexible and capable time-history plotting. 

7. Pseudo- flight creation. 

8. In-line formula spec if ica t i on and evaluation. 

9. Built-in analysis capabilities. 

10. Database installation and error-checking tools. 

These features will, be described in some detail in the 
following sections of this report. 
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Figure 1 .1 Basic TRENDS 
Multiple Users of Multiple Databases. 
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1.2 


REPORT STRUCTURE 


The structure of 


the remainder of this report is as follows: 


Section 2 
Section 3 
Section 4 
Section 5 
Section 6 


TRENDS OVERVIEW 
TRENDS HIGHLIGHTS 
DATABASE MANAGEMENT 
TRENDS DEVELOPMENT 
CONCLUSIONS 


Note: The conclusions presented in 
discussions of the lessons we have 
future expansion of TRENDS. 


Section 6 include a list and 
learned as well as our plans for the 
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Section II 


TRENDS OVERVIEW 


2.0 TRENDS OVERVIEW 

This sectior discusses the TRENDS concept ami the considerations 
:^h„ave shaped the system. An overview .1 the TRENDS database 
structure is presented. A summary ot the TRENDS capabilities 
is shown in Figure 2.1. 


2.1 


TRENDS CONCEPT 


The initial 
flight data 
min/max dat 
product was 
system. Th 
be immediat 
not just to 
responsible 
results of 


requirements were to provide a software system to access 
via a search option and to be able to display statistical 
,i graphical I y and in tabular printed form. The final 
an interactive, full-blown, menu-driven database operating 
,» uniqueness of the concept was that the database was to 
n ly accessible to the rotorcraft engineering community and 
the flight-test engineer who, in the past, would have been 
for disseminating what he or she concluded were the salient 
the flight test some time (perhaps years) later. 


2.1.1 Interact ive 

The interactive nature of TRENDS is key to the system. The user must 
be able to interrogate the database directly rather than have to submit 
a batch iob or wait for a data-processing person to generate it. Batch 
action has a purpose, as does the delegation of tasks to support 
personnel, but only by hands-on interaction can the serious user most, 
efficiently exercise the tools and the database to solve his problems. 
On the other hand, the interaction must he simple, robust, and rapi so 
that senior engineers and managers (or any other users) don t get 
frustrated by complicated and arcane commands and slow response. The 
emphasis in the design and development of TRENDS has been to provide an 
interactive tool which is not only capable, hut which can be easily 
learned and easily used, and which is robust and efficient. 

2.1.2 On-line Database 

TRENDS was designed to utilize an on-line database in the interests 
of interaction and efficiency. That is, the information is always 
accessible, with no requirements for tape-mounts, disk-mounts, or 
special programs to he run each time to properly install the data 
in the database . Users can also get immediate access to the 
flight-test data without having to go through the effort ot devising 
a structure and filling their own databases. 


2-1 



TRENDS CAPABILITIES 


USAGE: 

• MENU DRIVEN 

• USER-FRIENDLY 

• QUICK RESPONSE 


• INTERACTIVE 

MULTIPLE USERS SELF-CONTAINED HELP 

REMOTE USERS GRAPHIC TERMINAL SUPPORT 


USER PSEUDO FLIGHT GENERATION > FROM: 

DATA SEARCHING NARRATIVE SEARCHING DATABASE SEARCHING 


DATABASES: 

MULTIPLE FLIGHTS 
MULTIPLE ROTORCRAFT 
- > XV- 15(702 & 703) 

— > UH-60 


> ON-LINE 

MULTIPLE DATABASE TYPES 

--> FLIGHT, WINDTUNNEL, MATH MODEL 

MULTIPLE DATA TYPES 

-> TIME HISTORY, MIN/MAX, NARRATIVE 


PLOTTING TYPES 

TIME HISTORY 
MULTI-FAMILY 
MULTI-PLOTS/Page 
SNAPSHOTS 


AMPLITUDE SPECTRA 
HISTOGRAM 
MULTI-TEST PTS/Page 
DATABASE COMPARISON 


MIN/MAX (Statistical) 
HARMONICS vs MIN/MAX 
CROSS-PLOTTING 


PLOTTING ATTRIBUTES -> user friendliness -> automatic labeling 

Easy k> change Scales & Labels Easy Plotting of User Defined Functions 

Easy Filtering & Storing of data Easy Plotting from 1 ~> 16 plots/pagc 

Easy Access to Help Features Easy Editing/Saving/Recalling of Plot Setups 

Transparent cross plotting of parameters having different data rates 


PRINTOUTS & VIEWING 

STATISTICS (EACH PARAMETER) 
DERIVED PARAMETERS 
USER DEFINED FORMATS 
FUNCTIONS (USER DEFINED) 

DATA SCANNING/SEARCHING — 

FLIGHT LOGS 
PROJECT LOGS 
FLIGHT DESCRIPTIONS 

ANALYSIS/In-line Analysis Tools: 

FORMULA EVALUATION 
REGRESSION 
CONVOLUTION FILTER 
CYCLE AVERAGING 


STATISTICS - KEY PARAMETER GROUPS 
PARAMETER DEFINITIONS/PARAMETER GROUPS 
HARMONICS 

ALL NARRATIVE, NUMERICAL & HELP DATA 

■-> Iteratively 

NUMERICAL DATA (Multi-Parameter) 
NARRATIVE DATA (Multi test points) 
PARAMETER NAMES/DEFINITIONS 


DERIVATIVE & INTEGRALS EVALUATION 
FAST FOURIER TRANSFORMS(FFT) 
SIMULATION/GTRSIM/Gateway 
DAT AMAP/Gateway 


Figure 2.1 TRENDS CAPABILITIES 
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f TRFNDS feel that nowadays the only data that ^ 
The developers of TRENDS that are on line. The 

ever be looked at by most user acce88e d, manipulated, plotted 

ease with which archived a a . _ has caused users to ask 

and analyzed during an interac ive - old test data residing 

fur new TRENDS databases to be established tor o 

on tapes or disks in various formats. 

2.1.3 Multi-Rotorcraf t 

TRENDS has the ability to move from ^ single forking 

vu is i- n tin 60 to BV-360 wind tunnel data) within a siu&j. 


2 . 1.4 User-friend Liness 

User-friend Liness 

when it. is absent 
ness of TRENDS du 
interface is cons 
workload, the tru 
which may have to 
options as logica 

user-friendliness 

the numerical dat. 


is difficult to define explicitly, but easy to spot 
Great concern has been given to the use r- f trend Ir- 
ving design and development. Each change to he user 
idered carefully as to the logic of prompts, the user s 
stration it is likely to cause, and the input mistakes 
be handled. A main menu that shows all of the mam 
1 functions is felt to be a good first step towat 

Descriptions and supporting narrative to accompany 
a are also user-friendly. 


. . , 1t . A rnncise well-planned visible menu , in conjunction 

2. 1.4.1 Main Menu Layout . A cine • requirement for user- 

wit, h patterned prompts and on-line help . “ a avai lable to the 

t . A l)no „ c In the TRENDS menu, all major choices avduflu 
f i lend 1 ine •> s . , L au i., 0 *. n branch into an unknown 

user are presented at once » on-line help is easily av.llahle 

tiee type ,,t ««»• B ‘“ £ T ^„DS main menu is column-oriented by logical 

for each menu item. The ratesorize the listed menu 

function. The six column headers, which cat g 

items are: 


C0NTR0L- 


-> database selection; terminal type; hardcopy option; 
user functions available; exrt from TRENDS 

DESCRIFTIVE-> project description; ^narrlhve • ^ ^ 

flight descriptions; search on narrative, 

calibration data 


DATA -SC AN -- 


> search on numerical data; show key-parameter data; 
view parameter statistics; customized printout; 


PLOTTING 


locate available time-history data 

> time-history plotting; group plots of performance 
parameters; plotting of statistical data; 
time-history plotting of one parameter tor 
many counters; families of plots for statistics 
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ANALYSIS 


---> gateway to analysis programs DATAMAP and GTRSIM; 
plotting and printing of harmonic amplitudes; 
derivation and plotting of amplitude spectral 
histogram plotting of loads data; 

---> help; parameter definitions; derived parameters; 

user-generated file treatment; time-history groups 

The order of features within the menu is a matter of concern and is 
frequently reviewed. Patterned dialog is used to effect the user- 
computer interface once an option has been selected from the main 
menu Because not all users prefer the same option names or orders 
within the menu or the same dialog, certain compromises have been 
incorporated to please a broad a range of users. 

The combination of a menu with prompting inside the menu items is 
consideted by the authors to he the best user-friendly user-interface 
format. Forms or pull-down menus and icons have aesthetic appeal, but 
require very specific terminals, mice, joy-sticks, etc. TRENDS serves 
a wide variety of interface hardware with a standard scrolling menu, 
but also provides a screen-managed version of its menu for particular 
terminals to enable menu-item selection by means of keyboard arrows. 

2. 1.4. 2 Supporting Narrative. A database operating system for test data must 
include narrative to support the numerical data if is to be considered 
user-friendly. TRENDS includes data item descriptions, flight and 
test descriptions and project information among its available narrative 
data. Test descriptions are related to numerical data by flight and 
test-point numbers. 

2 ' 1-4 ' 3 IIIpMnc P ! Cif t 1Cat I™ Dlal ° P ’ Ue ' 0ne of the n,ost »ser-friendly features of 
TRENDS is the simpie-yet-powerf ul , flexible, plot-specification dia- 
logue. The user may specify as little as the names of the parameters 
used for abscissa and ordinate. TRENDS will then provide scales, 
labels, headers and plots. The user may, alternatively, specify ’ every- 
t ring through a straightforward, logical entry syntax. On-line help is 
available at every step of the dialogue. P 

2. 1.4. 4 Input Error Checking. It is not necessary to crash the system to find 
whether a user’s input is proper or if a parameter exists, provided the 
software performs suitable checks. TRENDS checks every character input 
by the user which could be either a parameter or a function of param- 
eters and determines whether there are any illegal entries. Certain 
checks are made immediately to determine whether requested data exist 
m the database. In the name of user-friendliness we are able to 
eliminate many crashes for incorrect parameter names which might crash 
the system and frustrate the user if not screened out. 

2. 1.4. 5 On-line Analysis. TRENDS lets the user specify formulas involving 
stoied parameters and evaluates these formulas immediate ly for plott inp 
searching or listing. In addition, many standard analyses are provided” 
within the system. It is not necessary to progiam other software or to 
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leave TRENDS in order to filter the data, fit. the data to polynomials 
or perform spectral analyses. 

2.1.5 System Speed 

Great concern has been given to computational effi< lenc.y. The h ( o 
VAX-specific file structure enables direct (i.e., keyed) access to the 
information of interest, without extra searching or dat a- reading . 

Opening of extra files has been regarded as a time-consuming overhead 
item and has been held to a minimum. The result of the effort and 
concern is s system which can search and display large databases 
rapidly, thereby minimizing the user’s effort and frustration. 

2.1.6 User Softwaie Exclusion 

Potential users of the data often ask how to get the archived data into 
their own favorite analysis programs or plotting packages. Modules 
have been supplied for some users to take data, but this is not 
standard. ''he choice was made to provide the tools most needed (e.g., 
plotting routines, spectral analysis) along with the data, so that 
engineers don't have to devise, interface, and check out tools to do 
their jobs. This method of operation has been happily accepted by most 
of the engineering users of TRENDS. Additional requested features and 
capabilities have been developed and incorporated into the system when 
they have been judged to have general interest, or application. A 
provision has also been made to access certain other software tools 
(i.e., DATAMAP and GTRSIM) through TRENDS and to enable them to use 
data from TRENDS’ databases. 

2.1.7 Documentation 

Users can usually find all the help they need in TRENDS during a work- 
ing session. User help includes brief descriptions of each menu item 
and general hints on the use of the system. It also includes detailed 
help and examples for each program feature. The user can also call up 
information concerning the database, the project., and the stored 
variables as part of the normal access of narrative data. 

In addition TRENDS is supported by several manuals: 

1. TRENDS User’s Manual 

2. TRENDS User’s Reference 

3. TRENDS Procedures Manual 

Copies of these manuals may lie obtained by calling Mike Bondi at NASA 
Ames, code FAF, (415) 604-6341 or Bill Bjorkman at. AMA (415) 964-1844. 
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2.2 


TRENDS DATABASES 


Engineering tests, lie they flight tests, wind tunnel Jests, simulations, 
or any other tests during which experimental data are collected, have 
common characteristics. The way that TRENDS accommodates test data 
from multiple sources, multiple sensors, and multiple test points is to 

1. Assign a separate directory for the test data for each vehicle 
(e.g., segregate XV-15 data from UH-60 data) 

2. Assign a unique index to each test point 

3. Assign a mnemonic to each sensor and store all of the data 
for that sensor in a file named for the mnemonic (exceptions 
wiil be discussed iater) 

The path to a test data point is thus given by specifying the test 
vehicle (which leads to the directory), the sensor mnemonic (which 
leads to the file), and the test -point index (which leads to the 
record of interest). 

2.2.1 Test Points 

The test-point index is commonly called a "counter" in TRENDS because 
there is a physical counting device in the XV-15 by which the pilot 
increments the counter for each new test point. This counter is 
recorded with the other test-point data. XV-15 counters are not reset 
between flights and thus continue to increase. The counter indices for 
XV-15 aircraft 703 are now around 14500 for flight 234 (they are also 
incremented during ground and hangar runs). Counters for UH-60 tests 
are constructed from flight and run numbers to create a unique test- 
point index, since run numbers are reset for each flight. Wind tunnel 
counters are also constructed to give the uniqueness TRENDS requires 
for rapid record access. The term counter is often used to mean the 
test-point event as well as the index of that event. Thus "counter 
duration" means the recorded length of the test-point event. 

Each test point of a well-planned engineering test project serves a 
planned purpose. That purpose or the specific conditions for the test 
point can usually be described in a few key words of narrative. TRENDS 
stores and enables a search on these short test -point descriptions as 
part of the database information. This description, together with 
recorded and derived data from all of the sensors, completes the 
information stored for each test point and is indexed (i.e., related 
and located) by the counter number. 

2.2.2 Data Types 

Most of the numerical data recorded during engineering tests is in the 
form oi time-histories which consist of a time-series of samples of the 
measured output from each sensor. Many of the rotorcraft test points 
are taken at a trimmed or steady condition where many time-histories 
are basically constant and where the mean values of such parameters are 
just as useful as the time-histories and are much more economically 
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stored Other statistics besides the mean are also useful (especially 
per-rev statistics for rotorcraft), so TRENDS precomputes some of them. 
Such statistical measures (some of which are listed in paragraph 3.2.5) 
are sometimes called H In /Max data. In the case of wind tunnel data, 
time histories are usually not available and only the mean values are 
recorded. As noted earlier, a TRENDS database is completed by adding 
narrative information in support of the numerical data. 

2.2.2. 1 Min/Max. This terminology came about because of a digitizing 

process in which only the minimum and maximum values of the time 
during each rotor revolution were stored as digital values. These 
were then used to derive single statistical values for each sensor 
over the time span of the counter for (1) the average "steady" value 
over all revs in the counter. (2) the average oscillatory value, and 
(3) the inaximim oscillatory value. 

The steady vaLue for one rev is the average of the minimum and 
maximum values, while the oscillatory value is ball of the difference 
between the maximum and minimum values. Such measures are only 
meaningful for an engineering test which is influenced by a cyclic 
phenomenon such as a turning rotor, but statistical measures of some 
kind (at least the mean value) serve well in any engineering database 
system to describe the "big picture" covering a collection of different 
test points. The term "Min/Max" is often used to refer to all such 
statistical measures in TRENDS. 

TRENDS stores a set of statistical measures (Min/Max data) for eai h 
parameter and counter of each database. The particular statistics are 
customized for the particular database (see paragraph 3.2.5). TRENDS 
has many features tor searching, listing, and plotting Min/Max data. 

2. 2. 2. 2 Time-History. TRENDS accommodates parameters collected at different 
data rates with total user transparency when plotting and/or cross- 
plotting. Tie requirements for storage and use of time-history data 
differ between sensors or parameters. For example, altitude or air- 
speed data ate of interest only at a low sampling rate, but must span 
the duration of the counter. On the other hand, bending moment 
data for a blade element must be sampled at a high rate to lie useful, 
but need not necessarily span the full counter duration. TRENDS treats 
several types of time-history data and several "groups". Groups 
combine several test-data parameters of similar type (e.g., loads, 
performance, aeroelastics ) . Some types of time-history data are 
filtered and decimated before being stored in the database. Not all 
groups of time-history data are stored for a given counter because of 
storage limitations. The decision of whether to store certain groups 
is made by project engineers, as is the decision about appropriate 
filtering and decimation nates. 
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2. 2. 2. 3 Narrative. The numerical information stored in a TRENDS database is 
supported by extensive narrative (textual) information, including 

1. Test-point descript ions 

2. Detailed flight descriptions 

3. Flight logs (brief descriptions) 

4. Project data on the aircraft and test program 

5. Parameter (data-item) descriptions 

6. On-line help for the user 

The test-point, flight, and parameter descriptions may he searched by 
the user. That is, the user can specify character strings (words or 
phrases) to be used in locating certain stored information. The set 
of related test points resulting from a text search may be stored and 
used to identify the data region for subsequent plots or searches. 
Stored narrative information for flights and counters is used for 
automatic labeling and headers on plots. 

2.2.3 Database Management 

The tasks of database management are not given to the general user, 
according to the TRENDS operational philosophy, but to a database 
manager. The manager is responsible for filling and editing the data- 
base and for monitoring the quality of the data. The manager must find 
enough disk space, reduce and store the data, assess and fix or report 
bad data, and process requests from users. Most database managers to 
date have been support personnel, but selected engineers were given the 
responsibility for managing the UH-60 flight-test database. 

Menus are provided for the database managers to integrate the 
processes and help in the filling and editing tasks. Supporting files 
are updated automatically in most cases as part of the filling process. 
Programs for assisting in the structuring and entry of narrative data 
are provided as part of the management software. Database management 
considerations will be discussed in Section IV. 


2.3 DATABASES AT AMES 

Several rotorcraft test and simulation databases are maintained at 
Ames. Many similarities may be observed among them. They are all 
characterized by having multiple parameters and data regions 
(i.e., runs or test points) and they all have some narrative 
descriptions to support the numerical results. Databases differ, 
however, because not ail objectives are the same and not all instru- 
mentation systems and data- reduct ion systems are the same. Each 
of the current databases at Ames has its own unique aspects. 


2-8 


2.3.1 


XV- 15 Database 


TRENDS was developed to treat XV-15 data; hence, most of : the current 
storage is d-svoted to the XV-15. Among the unique aspects of the XV 
database are the following: 

1 The counter sequence is not reset for each flight. 

2. Four-character itemcodes are used to identify the parameters. 

3. Time-history data are categorized into groups. 

4 . Slopes are calculated and stored for some items. 

5. Calibrations are included in the database. 

6. There are two XV-15 databases, one tor each aircraft. 


2.3.2 UH-60 Database 

TRENDS was used to support the Phase I NASA/Army flight text of the 
highly instiumented UH-60 at AEFA and has become a basic tool of th 
flight-test engineers associated with the project. Some unique aspec 
of the UH-60 database are the following: 

1. Appointed user-engineers, not support personnel, are the 
Database Managers. 

2. Counters are composed of flight and run numbers. 

3 Both mnemonics and itemcodes identify data items. 

4. Three databases, representing different data releases, are 
currently accessible. 

2.3.3 Wind Tunnel Databases 

The TRENDS databases at Ames include wind tunnel databases for HARP and 
BV360. These were built from input formatted disk files made from 
data recorded at the DNW facility in The Netherlands. Counter numbers 
were derived from non-numeric run numbers. "Flight" numbers were derived 
from the test date. Only run descriptions and mean values of parameters 
are stored in the database because neither time-histories nor 
statistics other than the mean were recorded. 


2.3.4 Simulat ion 

Results frcm the tilt-rotor mathematical model simulation, GTRSIM, (see 
Section 3.4.2) are stored in the user’s directory as a database which 
may be accessed by the GTRSIM/ TRENDS interface software for listing, 
Plotting, cr comparisons. Counter numbers for simulation runs are 
supplied bj the user or, if inputs to GTRSIM have been taken from the 
flight-test database, are automatically supplied (as the flight-tes 
counter number). The form in which simulation results are stored 
differs from the form used in the aeronautical test databases. 

Future efforts will change the form of the database for simulation 
results to bring it into agreement with the flight-test databases. 
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Sect ion III 

MAJOR HIGHLIGHTS OF TRENDS 

3.0 HIGHLIGHTS SYNOPSIS 

This section presents the major highlights of the use of TRENDS to 
access engineering test, databases. These highlights are the menu, the 
plotting features, the searching capabilities, and the analysis tools. 
This presentation is not an exhaustive compilation oi the capabilities 
of the system, but rather a representative demonstration (mostly by 
means of examples) of some of its most powerful and useful features. 

Many of the system’s good features are subtle, user-friendly imple- 
mentations which can be appreciated only by using the system. 

Not all of the capabilities of TRENDS will be addressed here, hut the 
menu and the plotting and searching features and the analysis tools will 
each be discussed in some detail because these features illustrate the 
full power of TRENDS. 

3 . 1 TRENDS MENU 

The layout and presentation of the main menu have been carefully 
designed to provide access to the various capabilities of TRENDS in a 
logical and easy-to-use way. The main menu of TRENDS is shown below. 


*** TRENDS MENU *** 


Cont rol 

De script i ve 

Da ta-scan 

Plot ting 

Analysis 

Usage 

703>TAIL NO. 

PROJECT 

SEARCH 

TTMEFITST 

DATAMAP 

HELP 

GR>TERMINAL 

DATABASE 

KEYS 

PERFPLOT 

HARMONIC 

ITEMDEFS 

N0>Pl.THPCPY 

LCGSCAN 

V LEW 

MTNMAX 

SPECTRA 

DERIVED 

FUNCTION 

FI. I.GHTS 

C PRINT 

QWIKPLOT 

LOADS 

FILES 

EXIT 

WC RDSCAN 

FIND 

MULTI FLT 

SIMULATE 

GROUPS 


CA LIBS 


COMPARE 




The menu showr is for XV-15 databases. The column headings express the 
general function of the menu items shown below them. This categoriza- 
tion is frequently reviewed to make it as helpful as possible to the 
user. Each menu item corresponds to a program feature (i.e., program, 
subroutine, oi process) which will, upon invocation, prompt, users for 
further specifications of what they want, through other menus or speci- 
fic questions . Some minor differences will lie seen in the UH-60 menu 
because some of these menu items are not. applicable to the UH-60 
database. A ptogram feature is invoked by typing the name of that, 
feature in response to the prompt "YOUR CHOICE A user need not. type 

the who le name, but only enough of it. to make the choice unique. This 
ability to abbreviate helps avoid typographical errors and is especi- 
ally favored by poor typists. When the program feature has been 
completed or purposely interrupted, TRENDS always returns to this main 
menu unless the choice is ’’EXIT” . 
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3.1.1 


Brief Description of Menu Items 


When the menu item "HELP " is chosen, the following brief descriptions 
of the menu items and other help-options are shown. 

DATABASE ACCESS OPTIONS 
*********************** 


TAIL NO. 
TERMINAL 
PLTHDCPY 

function 

EXIT 


Change aircraft of interest 

Assign new terminal characteristics 

Change plot-hardcopy option 

List /verify/edit the defined- fund ion file 

Exit the program, return to the operating system 


project 

DATABASE 
LOGSCAN 
FLIGHTS 
WORDSCAN 
CAL IBS 


Display project and aircraft Information 
Show a brief summary of flights in the database 
Scan the flight log and search descriptions 
Dispiay some or all flight descriptions 
Scan counter descriptions for words or strings 
View calibration data by item and flight 


SEARCH 

KEYS 

VIEW 

CPR7NT 

FIND 


Search for a specific set of flight conditions 
Show value of primary condition keys for a flight 
View item statistics for specified counters 
PRINT .item statistics in your own custom format 
Find counters with data for time-history items 


TTMEHTST 

PERFPLOT 

MINMAX 

QWIKPLOT 

MULTIPLT 

COMPARE 


Plot time-history or spectral data 
Plot, performance items 2X2* 3X3 or 4X6 per page 
Plot Min/Max-per-counter data (statistical summaries) 
Quick-plot time-histories for multiple counters 
Plot families of Min/Max data 

Co-plot time-history data for two different databases 


DA TAMA P 

HARMONIC 

SPECTRA 

LOADS 

SIMULATE 


Analyze time -history data with DATAMAP 
Display n-per-rev harmonics vs. Min/Max items 
Spectral analysis amplitude display (0-60 Hz only) 
Show Min/Max/ rev data and loads distribution 
Set up and run the tilt-rotoL math mudei program 


HELP 

ITEMDEFS 

DERIVED 

FILES 

GROUPS 


Show this list of keyword descriptions 
Show/ search iteincodes and definitions 
Show tlie derived pseudo-items 
Scan user- created files 

Show tiie itemcodes in the time-history groups 


Further, more-detailed descriptions of each of the program features 
and their use may be called up by the user. 
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TRENDS-User Dialogue 

Once the uee. has selected a menu item, TRENDS will prompt for the test 

1E a i 

"ses a mathematical expression can he specified as we as a simple 
it entcode at his point. There may be move prompts for Hemrode. as 
in SEARCH, where the user sets up a condition template tor defining 
success. Th ; prompt may not specifically ask for itemcode, as in 
MINHAX whe r i the user is actually prompted for abscissae anc ore m . 
u s^’up the plot format. In any case, having specified the i emcode, 
the user is prompted for a data region (e.g., the f 1 ight number ). 

TRENDS then reads a supporting file, FLTCTRMAP . KEY, to ^ ", mies 
counters are in the specified flight, opens the itemcode tiles (flies 
in the database, containing the Min/Max statistical values for each 
data item) and reads in the data for the requested counters. Then, if 
the selected menu item was M INMAX or MULTI FLT , TRENDS proceeds to 
produce plots; otherwise, the information is displayed in printed form. 
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Figure 3.1 Dialog and Action Taken by TRENDS to 
Produce Min/Max Statistical Data 
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3.2 


PLOTTING 


1 . 
2 . 
3 . 

4 , 

5, 
6 
7 


Another highlight of TRENDS is its pi ott ing ™pabi litv ™e^est.^ 
characteristic of TRENDS' plotting implement ation^is^^ want 

write titles automatically. The user may optimally spe , y . u 
scales, labels, and titles by means of a simple and logical mp 

syntax . 

The various plotting teatores which will be described are 

TIMEHISTt TRENDS* primary rime-history display feature 
FFFFPLOT: A time-history snapshot of pe t fonnance 

OWIKPLOT • A "strip-chart" plot, for multiple test points 
SpS™"' Spectral analysis plots of amplitude vs. frequency 
M1M1AX ; Cross-plots of Min/Max statistical measures 
HARMONIC! Plots of harmonic amplitudes versus Min /Max values 
LOADS: Frequency distribution histograms of pet-rev samp 

versus load range. 

M , nv different graphics terminals are served by TRENDS. A low- 
resolution printer-plot, capability is available tor nongrap hie te rmi- 
nals . Hard copies of the plots may be generated in adrlit ion to 
instead of. screen pints. The hard-copy plots can be routed to laser 
Tr Versatelc printers at Ames via dialogue supplied at exit from TRENDS. 

3.2.1 Time -History Data 

foafuroc mAv Itp used to plot - t ime -history 
Several menu items or program features may be useo r r 

data The most, used and most flexible of these is T1MEHIST. 

Enable of plotting from one to three plot, per page with one or 

two curves per plot. Each plot page may thus contain from one to six 

curves The curves may represent evaluations of formulas involving 

recorded time-histories. They may also be polynonuals resulting ro 

specified by the user! E*a of time-history plots are shown rn 

figure 3.2. 
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3. 2. 1.1 


Functions . The abscissa a "|* "'^^1 spl:il ^^38 ’ ^he 

The /ollovin^aUd examples show some 
ol the formula-evaluation capability o 


Prompt 


Response 


3. 2. 1.2 


(Ml 43 + M107) / 2 

(Ml 4 3 - M107) / 2 
POLY (CP* SIN (ALPHA) , 3) 

-.5 * SFUNC * GTABLE(VT) 


PLOT 1 X-AXIS : 

C-CURVE 1 : 

or ._> Y-CURVE 1 : 

or __> Y-CURVE 1 : 

These examples show algebraic combination of parameters a third-order 
polynomial (POLY) of a formula involving parameters and the use o 
stored formula (SFUNC) in a formula involving a table loo up 
TPFNDS parses the inputs to test their syntactical correctness and 
disallows^! he entry if it is improper. This formula-evaluation feature 
is available for use with Min/Max plots and for searches as well as for 
time history data combination. Other available functions include 
integrals end derivatives and a digital (convolution) filter in combi- 
ir ii.h L»U.. The syntax for formula entry i. described in 

Appendix B 

labels and Scales. The examples shown above would all result rn 
aot'iatic seal ing and labeling by TRENDS . If users want to speurfy 
these, they would enter (for example): 


3. 2. 1.3 


PLOT 1 <-AXIS 


AVERAGE TORQUE = (M143 IM107 )/ 2 , -50000 , 100000 , 2500U 


3. 2. 1.4 


This specification gives "AVERAGE TORQUE" as the abscissa label and 
scales the abscissa from -50,000 to +100,000 in grid increments of 
25 000. Plot headers (titles) are usually automatic ( showing tligh 
and counter descriptions along with aircraft name) but may be 
overridden completely or in part with user-specified titles. 

Editing TRENDS contains an editing feature for recalling and 
(optionally) changing previously entered plot -tups This feature 
lets the i ser save a complex plot specification tor later ■ 
another flight or counter. It also lets the user easily change one 
line (ordinate or abscissa) without having to reenter the rest of the 

setup spec if it: a t ion . 

Storing. TRENDS has a provision for storing t ime-hi stot ies in the 
user’s^ directory for later recall. This is particularly useful for 
storing derived time-histories such as filtered time series, comp^x 
" , „ r polynomial recensions. Such stored time-series nay be 

«™ned ,y name for use in formulas. On. might .tors the OU.t.d 
version of a parameter’s time-history, then teoall rt to use in a 
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formula for the residua 1. (difference) between the "raw" (unfiltered) 
and filtered representation of the parameter’s behavior. This type of 
storing is different t rom storing formulas, because the actual data 
values for each sample point are stored by the counter for which the 
function is evaluated, while stored formulas are reevaluated from the 
database and from previously stored time-histories. 

Another useful means of storing time-histories is available in TRENDS 
This feature permits writing raw or derived time-histories to an 
output file in ASCII format for transmittal to another computer, such 
as a PC. This operation is implemented by use of the PRINT command 
in TIMEHIST . 

3. 2. 1.5 Help. TRENDS provides help menus for all of the various plotting 

questions one might have while using TIMEHIST or M INMAX (the most-used 
plotting features in TRENDS). These menus are called out by the user 
by typing a "?” at any prompt. The help-menu items include provisions 
for examining the available database entries as well as instructions 
and examples. The TIMEHIST help-menus are 

TIMEHIST SETUP HELP TOPICS 


AZIMUTH COMSCALE CVF DERIV EDIT EXAMPLES FORMULAS 

FREQ GENERAL INTEG INTERVAL MATHLIB MNEMONIC POLY 

PRINT RECALL REPEAT SORT STORE SYNTAX UNSTORE 

* or ALL 


TIMEHIST DATA-REGION HELP TOPICS 


DATABASE EDIT EXAMPLES 

PRINT RESCALE SAVE 

W80,W132 +(xhair) 


FINDCTRS HARDCOPY INTERVAL 
SYNTAX TERMINAL TITLE 


MYDCS 

TSHIFT 


3.2.2 Data Snapshot of Test Point 

PERFPLOT provides a means for drawing 4, 9, or 16 time-history plots of 
different parameters on the same page in a square array. This feature 
is useful for grouping flight-performance parameters for a visual 
quick look at a counter. The current implementation permits no formula 
evaluation or scale or label specification and permits only time as the 
abscissa. Only one curve is allowed per plot. On the side of flexi- 
bility, the user is provided with a capability for specifying which 
parameters are to be plotted and where they will appear on the page. 
When one of the specified parameters is not available for the specified 
counter, its plot space is left blank except for the parameter’s name. 
The user may save plot setups in named files for latei recall and 
modification. Examples of performance plots are shown in figure 3.3. 
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3.2.3 Strip-Chart Plots for Multiple Test Points 

QWIKPLOT provides the means for plotting time-histories of a data 
item s behavior versus time with up to five test points represented 
per page. The plot setup process is extremely simple, and the special 
plotting features such as scaling, labeling, and formula evaluation are 
precluded. TRENDS will take a specified flight or set of counters, 
divide the counters up into groups of five, and quickly display the 
strip charts with a time-scale which is common for all plots of a 
page. This feature gives a "quick look" at the time histories so that 
the analyst can rapidly scan the data for anomalies or notable behavior 
for further detailed study. QWIKPLOT examples are shown in figure 3.4. 
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Figure 3.4. QWIKPLOT Example 
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MRPR Lbs MRPR Lbs 

100 200 300 -IK -0.5K 


3.2.4 Frequency Data P ots 

TRENDS' analytical capabilities include Fast Fourier Transform (FFT) 
analyses of spec fied time-histories. The specified time-histories may 
be formulas involving several stored time-histories or functions of 
time-histories sjch as stored filtered functions. TRENDS plots the 
amplitude spectra versus frequency, one curve per plot, but up to three 
plots per page. This type of plot may be produced by specifying the 
abscissa to be FREQ in TIMEHIST or (in simplified form) by using the 
menu item SPECTRA. Examples of frequency data plots are shown in 
figure 3.5. 
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Figure 3.5. Spectral Examples 




3.2.5 Statistical Data Plots 

Statistical data (Min/Max and harmonic) are plotted by MINMAX, MULTIPLT 
and HARMONIC. Specification syntax of MINMAX is very similar to that 
of T1MEHIST and all of the rules for scaling, labeling, and formula 
evaluation are identical. The data region for one MINMAX plot is a set 
of counters (e.g., a flight or a pseudo- flight ) for which points are to 
be plotted. As with TIMEHIST, each plot page may contain up to three 
plots and one or two "curves" of discrete points per plot. MULTIPLT 
differs from MINMAX in that each MULTIPLT "curve" represents the same 
ordinate expression (e.g., formula) for a different set of counters 
while each MINMAX curve represents a different ordinate expression for 
the same set of counters. HARMONIC plots prestored harmonic amplitudes 
of data items computed from the one-per-rev versus Min/Max statistics 
or expressions involving Min/Max statistics. HARMONIC also lists 
amplitude and phase versus harmonic number. 

The prestored statistics for the XV-15 and TJH-60 databases are 
XV- 1 5 Tilt Rotor 


AVS Average steady (average of per-rev (max+m i n ) / 2 ) DEFAULT 
OSC Average oscillatory (average of per-rev (max-min ) / 2 ) 

MAX Maximum oscillatory (max-min) /2 encountered on all revs 
SMO Steady value when maximum oscillatory value occurred 
CMN Algebraic minimum of all raw data samples in the counter 

CMX Algebraic maximum of all raw data samples in the counter 

FSC Full-scale value used (corresponds to 126 byte-counts) 
HMn nth harmonic amplitude (n between 0 and 6, inclusive) 

UH-60 Blackhawk 


AVG Average or mpan of ail of the recorded samples DEFAULT 
MAX Algebraic maximum of all of the recorded samples 

MIN Algebraic minimum of all of the recorded samples 

SDEV Standard deviation of all samples about the mean 
AVS Average steady (average of per-rev (max+min) /2) 

AVO Average osci.J Latory (average of per-rev (max-min) /2) 

V95 1 95th-percent. ile vibratory (952 vibs below this) 

MXV Maximum vibratory (oscillatory) value encountered 
SMXV Steady value when MXV occurred 

HMn nth harmonic amplitude (n between 0 and 15, inclusive) 

MINMAX permits the plotting of functions of any of these statistics 
against functions of any others. Examples of MTNMAX, MULTIPLT and 
HARMONIC plots are shown in figures 3.6, 3.7, and 3.8. 
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Figure 3.6. MINMAX Plots 
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Figure 3.7. MULTIPLT Multifamily Plots 
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Figure 3.8. HARMONIC Plot and Print Examples 
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3.2.6 Histogram Data Plots 


TRENDS contains a capability for conducting some elementary loads analysis 
through the menu-item LOADS. This program feature uses a compressed data 
form called "minraax-per-rev" (MMR) data, sorted for certain vibrational data 
items to derive a frequency distribution. This frequency distribution is 
displayed as a printer-plot histogram showing the number of samples in each 
load range for the full range of oscillations measured over the counter. LOADS 
also shows the MMR data values plotted versus rev number for each counter. 
Plots produced by LOADS are shown in figure 3.9 
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Figure 3.9 Load Plot Examples 
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J.3 DATA SEARCHING AND PSEUDO- FLIGHT GENERATION 

TRENDS databases may contain thousands of test points or counters, 
representing many test conditions and test, results. If the database 
weie very small, users could just scan their notes or a listing to 
find what they wanted. With a large database, users must search the 
database for those conditions in which they are interested. TRENDS 
provides several ways of searching the database. A search on 
numerical data values (i.e., Min/Max statistics or harmonics) may be 
conducted with SEARCH. A search on text strings in the test-point 
descriptions is enabled through WORDSCAN. Flight descriptions may be 
searched using FLIGHTS or LOGSCAN . Availability of time-history data 
in the database may lie determined through menu-item FIND. These 
search features produce a set of "success" counters when the search 
process finds the condition, text string, or available time-history 
data for which the user was looking. The set of 'success counters 
is often called a "pseudo- f 1 ight " or a "derived counter-set." Su«h a 
set of counters may be saved in the user’s directory by name and then 
recalled to initiate another search (with different, conditions), or a 
plot or tabulation. This search feature is one of TRENDS’ most power- 
ful and useful attributes. 

3.3.1 Scanning Numerical Data 

Numerical condition searches are carried out in TRENDS by SEARCH. 

This program feature lets the searcher define a "condition mask" or 
success template which defines a successful condition, then applies 
the condition mask to a specified data region (which may be the entire 
dat abase , one or more flights, or a pseudo-flight.) to locate counters 
which satisfy the desired conditions. The conditions are specified 
by defining allowable bounds (i.e., a success- range of values) for 
each test, function. The test function is an expression in the Min/Max 
statistics or harmonic amplitudes (see 3.2.5). Of course, the test 
function may just be a simple statistic such as the mean value of 
airspeed. As many as 50 test functions are alJowed tor one search, 
but most searches use three or fewer. Condition masks may be saved 
by name for recall and (optionally) editing and application to another 
data region at a later date. 

3. 3. 1.1 Example of SEARCH. The following is an example of a numerical search 
in TRENDS. In this example we will search the XV-15 (A/C 703) database 
for helicopter-mode test points for which the total average oscillatory 
mast torque exceeds 5 l of the total aveiage steady mast torque. Heli- 
copter mo Je is signified by the pylon angle (D186) being above 85 degrees. 

85 < D186 < no upper hound 
The mast torque condition is 

0 < (M143 . OSC+H107 . OSC ) - ( . 05*ABS (Ml A3+M107 ) ) < no upper bound 
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The itemcode (e.g., D1.86) when written without an extension defaults to 
the average steady value. This example illustrates the use of functions 
of parameter statistics in defining the condition mask. Both of the 
conditions must he met for a successful search. A search initiated 
with this condition mask over flights 180 through 230 found 284 test 
points (counters) out of several thousand for which data were avail- 
able for those flights in the A/C 703 database. This set of counters 
was then saved under the name 0SCGT5PCT (along with a use r- suppl ied 
description) for later recall as a data-region specification for 
plotting or further searching. 

3.3.2 Scanning Narrative Data 

TRENDS provides a capability for computer-aided scanning of flight and 
test-point descriptions as a means of locating data regions of interest 
for further exploitation. 


Menu items FLIGHTS and LOGSCAN arp used to scan flight descriptions. 
Flight descriptions include brief titles for each flight (e.g., "FERRY 
TO DRYDEN," "TRACK & BALANCE," "AEROELASTICS , " "MANEUVERING FLIGHT") 
as well as structured ("PILOTS: DUGAN AND HARDY," "WEATHER: GUSTY") 
and unstructured ("NOTED OIL LEAK," "PILOTS LIKED THE NEW SIDEARM 
CONTROLLER") descriptive infoLmation. The following lines show some 
output from FLIGHTS. 


AIRCRAFT: 703 

FLIGHT: 180 (0217) 
FLT DATE: 8 FEB 84 
DIRECTOR: SCHROERS 


H/Q AND PILOT TRAINING 
LOCATION: ARC 
COUNTERS: 10254-10324 
PILOTS: GERDES / TUCKER /WILSON 


T/0 GW: 
CG: 

HRS TO I NSP : 
FLT TIME: 


13656 

300.0 

8.2 

2.0 


FLIGHT INFO: SCAS /HQ EVALUATION - PILOT TRAINING (WILSON) 

WIND: CALM TEMP: 51’ F BARO : 30.06/-175 

CONFIGURATION: NORMAL PREFLIGHT 

RH FUEL GAUGE CHECKED ON BENCH 
TAIL CAMERA INSTALLED 

FLIGHT NOTES: DIFFICULT TO TRIM WITH SCAS OFF 

PILOTS COULD NOT HOLD A/C IN 3/ 4" STEPS - 1/2" WERE OK 

A/C ROLLED TO THE LEFT IN LT&RT PEDAL STEPS 

A/C NOT HARD TO FLY WITH SCAS OFF - EASIER WITH SCAS ON 


Users who are unfamiliar with the flight-test projects can use TRENDS' 
searching features to locate flights of interest; flight-test engineers 
at Ames who use TRENDS do not often use this searching feature because 
they remember the flights when certain key events took place. TRENDS 
does provide a depository for all of the flight-descriptive narrative 
data, however, so that project managers and other investigators have a 
readily available source of this information even when the flight-test 
engineer is unavailable. 
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The most useful descriptive-data search capability has proven to be 
the program feature called WORDSCAN, which searches the test-point 
descriptions for key words or groups of words such as "HOVER," "LEVEL," 
"STEP" or "SCAS." WORDSCAN shows thp test -point’s time-duration and 
the types of time-history data avail abie in the database as well as the 
description. The test-point descriptions for the XV-15 database are 
taken from tne brief notes on the pilot’s card. They were not composed 
as structured strings with set keywords or. codes to help in a computer- 
ized search, but they are very useful nevertheless for locating 
counters of interest because they are usually phrased or abbreviated in 
the flight -test vernacular. UH-60 test -point descriptions are somewhat, 
better structured for computerized scanning. An example of WORDSCAN 
is given below. 

Another type of narrai i ve data which may lie searched by the TRENDS user 
is the parameter-descriptive type. The menu-item called ITEMDEFS 
provides a capability for locating the itemcodes or mnemonics for the 
sensors of interest. A search for "ANGLE OF ATTACK," tor example, 
would locate itemcode D008 for the XV-15 databases and mnemonic ALPHA 
for the UH-60 database. Users may also use ITEMDEFS to list all of 
the "CONTROL POSITION" itemcodes and their descriptions for XV-15 or 
"ROTOR PARAMETER" names for UH-60. 

3. 3. 2.1 Example of WORDSCAN. This program feature enables the computer-aided 
search for particular words (i.e., character strings) in the databased 
test-point, descriptions. Users may look for test points whose 
descriptions contain any of several specified words (an OR search) or 
all of several words (an AND search) or they may look for test points 
whose descriptions do not contain specified words (NEITHER and NOR 
searches). A search for "LEVEL" might miss descriptions for which 
"LEVEL" was abbreviated by "LVL," so the user might ask TRENDS to look 
for "LEV" or "LVL." As an example of the use of WORDSCAN, we will look 
for either "AFT," "FWD, " or 11 F/A" in the test -point descriptions of 
flights 225 through 228 of the XV-15 (A/C 703) database. WORDSCAN 
prompts "Look for:" and we respond with "AFT , FWD, F/A . ” (Note the 
implied OR.) Then WORDSCAN prompts "Flights:" to which we respond 
"225-228.” WORDSCAN Linds 28 test points, some of which aie 






Pilot Comments 

Dur a t ion 

T-H Data 

Fit 

228 

CTR 

13072 

SLOW FWD ACCEL 

52 . 849 

HQ 

FLt 

228 

CTR 

13073 

SLOW FWD DECEL 

33 . 933 

HQ 

Fit. 

228 

CTR 

13090 

1" AFT STEP 

9.805 

HQ 

Fit 

228 

CTR 

L 3091 

1" AFT STEP 

13.064 

HQ 

Fit 

228 

CTR 

13092 

1" FWD STEP 

7 .518 

HQ 

Fit 

228 

CTR 

13093 

1" FWD STEP 

11.172 

HQ 

Fit 

228 

CTR 

13094 

2" AFT STEP 

14 . 590 

HQ 

FJ t 

228 

CTR 

13096 

1.5" AFT STEP 

9 .912 

HQ 

Fit 

228 

CTR 

13097 

1.5" FWD STEP 

18.092 

HQ 

FI t 

228 

CTR 

13098 

3/4" AFT STEP SCAS OFF 

12.032 

HQ 

Fit 

228 

CTR 

13099 

3/4" FWD STEP SCAS OFF 

13 . 726 

HQ 

Fit 

228 

CTR 

13108 

3/4" AFT STEP 

12.809 

HQ 
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We save the counter numbers of these test points as psernlo- flight or 
derived counter-set FASTEPS. We then search this pseudo-flight for 
"SCAS OFF" and find five counters, which we save as FASTPSOFF for later 
control response investigations in T1MEH1ST . (See the example in 
paragraph 3. 3. 3.1 below.) 

3.3.3 Pseudo-Flight Generation Function 

As seen from the preceding examples, the results of searches may be 
saved by name as pseudo- f 1 ights which may be used again to specify 
the set of counters on which to do further searches. Pseudo-flights 
derived from numerical-condition searches (SEARCH) are of exactly the 
same form as those derived from narrative searches (WORDSCAN) . A 
pseudo-flight derived in SEARCH may tie used to specify the counters 
to be used in searching for a particular text string in WORDSCAN and 
vice-versa. Each pseudo-flight is saved in the user’s directory and 
is self -documented (i.e., the information is included along with the 
counters) by its creation date and a user-supplied description. 
Pseudo-flights may he concatenated or appended and stored under 
another name. A list of the user’s stored pseudo- flights may be 
obtained using program- feature FILER. This program feature also 
enables deletion of pseudo-flights from the user’s directory and 
copying of pseudo- f 1 ight s from another user's directory. 

3. 3. 3.1 Recall of Pseudo-Flights. The principal application of pseudo- f 1 ights 
is for plotting Min/Max statistics or harmonics (Ml UMAX, MULTIPLT, 
HARMONIC) for a set of related test points. TRENDS accepts pseudo- 
flights by name in response to the prompt for data region in any of 
Lhe plotting, listing, or searching program features. For example, 
the prompt-response dialogue for data region in MINMAX might be 

Enter flights: ALLHOVERS 

where ALLHOVERS is the name of a set of counters whose test -point 
descriptions included the word "HOVER." Pseudo-flights may be used 
to specify the families of points for each curve in MULTIPLT. For 
example, one might use SEARCH to define pseudo- fl ights "FYL0N30 , " 
"PYLON60 " and "PYLON 75" for families of test points flown at several 
different pylon angles, then use MULTIPLT to plot mast torque versus 
airspeed for those families. 

Another application of pseudo- flights is as a series of counters for 
sequential time-history plotting applications. The data-region 
prompt-response dialogue in TIMEHIST might he 

Enter counters: FASTPSOFF 

where FASTPSOFF is the name of a pseudo-flight of longitudinal steps 
with SCAS off, derived by use of WORDSCAN. TIMF.HIST would show the 
plots for each counter of the pseudo-flight one by one. If the 
"hardcopy-only" plotting option is selected, no user intervention is 
required to produce time-history plots tor the entire pseudo- f light . 
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3. A 


ANALYSIS 


TRENDS could Lave been designed as a tool for simply storing, retriev- 
ing and displaying flight-test data, leaving the task of interfacing 
the data with analysis tools to the individual user. Some TRENDS users 
with specialised analysis tools prefer that mode of operation, hut most 
appreciate having analysis tools integrated into the system. Some of 
the analytical capabilities of TRENDS are in-line functions (e.g., 
derivatives, filters, polynomial fits, formula evaluation), and others 
are expressed as gateways to other tools (e.g., DATAMAP , GTRS1M) . 
Analytical capabilities have developed according to the needs of users 
and will probably increase in the future as other needs are recognized. 

3.4.1 In-line Analysis Tools 

Most of the in-line analysis tools provided with TRENDS are for opera- 
tions on time -his t.ory data (e.g., derivatives, integrals, i liters, 
spectral analysis, cycle averaging), but some (formula evaluation, 
polynomial regression) are applicable to either time-history or 
statistical (i.e.. scalar) data. Each of these in-line tools is called 
out by the us?r via a structured syntax and/or keywords, with no 
requirement fir recompiling tire program or passing the data to another 
program . 

3. A. 1.1 Formula Evaluation. This extremely powerful and useful capability 

enables the plotting or searching of functions not explicitly stored 
in the database, but that are derivable from stored numerical data. 

The formulas may contain derivatives and integrals as well as library 
functions such as trigonometric functions, square roots, or table 
lookups. Users may simply want to rescale or bias a variable or 
change its units (to metric, for example) for plotting, or they may 
want to root-sum-square several parameters. These and many more 
possibilities exist within TRENDS under the category of formula 
evaluation. TRENDS contains a program feature (menu-item FUNCTION) for 
storing often-used or complicated formulas or expressions by name. 

These formulas may be used alone or within other in-line or stored 
formulas for plotting or searching applications. 

3. A. 1.2 Derivatives and Integrals. These calculus operations are among the 
operations permitted on time-senes in TRENDS. Ihese are useful lor 
deriving rates or for integrating rates when the desired quantities 
have not beer recorded in the test or for comparisons when both rates 
and position or angle data have been recorded. One use of the deriv- 
ative has been to derive ground speed from recorded radar tracking 
position date during XV -15 acoustics tests. Integrals have been used 
to compare measured angular data with that obtained by integration 
of angular rrte data. Implementation of these operations in TRENDS is 
as simple sums and differences of time-series, scaled appropriately by 
the time increment between samples. These operations may he used in 
conjunction with any <>f the other in-line operations with very few 
exceptions. One of i he exceptions is that differentiation of an ampli- 
tude spectrum is not allowed, but an FFT of the derivative of a time 
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history is legitimate. Derivatives and integrals are generally allowed 
in expressions and may operate on mathematical expressions as well. 

3. 4. 1.3 Fast Fourier Transforms. The FFT is available as an analysis 

tool in SPECTRA and TIMEHIST for analyzing the frequency content of 
a given time-series. The FFT analysis may operate on formulas or 
expressions involving several time-series as well as on individual 
recorded parameter time-histories. The algorithm used in TRENDS 
was taken from DATAMAP . 


3. 4. 1.4 Regression. Univariate polynomial regressions (i.e., polynomial fits) 

up to third order are available in both TIMEHIST and M INMAX . Regression 
is also automatically used to provide reference curves in HARMONIC. 

The polynomial least-squares fit uses the abscissa expression as its 
independent variable and fits the ordinate expression to it. The 
polynomial is evaluated for each abscissa point and line-plotted. 

The coefficients are not stored, but are displayed in the plot legends. 


3. 4. 1.5 Convolution Filter. This digital low- pass filter may be used in 
TIMEHIST to remove unwanted high-frequency components from a time 
series. The convolution filter is not recursive, but operates with 
the entire time-series, using a window (selectable as either Hanning 
or half-cosine) to produce a result which exhibits no appreciable lag. 
The time-series upon which the filter operates may be an expression 
involving several time-series. The filtered result cannot be used in 
a formula or expression directly, but may be stored by name and counter 
for recall and potential use in formulas. 


3. 4. 1.6 Cycle Averaging. Rotorcraft analysts are frequently interested in the 
behavior of some parameter as a function of rotor azimuth. TRENDS 
provides a capability (adapted from DATAMAP) for displaying rotor 
azimuth as the abscissa in TIMEHIST plots, using a technique known as 
cycle averaging. The averaging comes about because the time-histories 
differ somewhat from cycle to cycle (i.e., from one rotor rev to the 
next) and the analyst is usually more interested in Hie commonality 
than the differences, so the data from a specified number of cycles are 
averaged together for display. Each cycle is broken into equal incre- 
ments of azimuth and then the measured data are interpolated to the 
times which correspond to each discrete azimuthal value. Neither the 
XV-15 nor the UH-60 instrumentation systems actually measures rotor 
azimuth, but rather provide a blipper or trigger (i.e., a hit in a code 
word) to signal when the rotor passes a certain point in its cycle. 
Rotor azimuth is derived from the blipper signal under the assumption 
that azimuth angle is a linear function of time over each cycle. 
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3.4,2 


Simulation 


Aircraft simulations are usually not integrated with flight-test 
analysis tools such as TRENDS and it is a major job to make other than 
gross comparisons of simulation and flight-test results. One non-real- 
time (i.e., off-line, strictly numerical) simulation, GTRSIM (Ref. 1), 
has been inegrated with TRENDS. This "Generic Tilt-Rotor Simulation" 
is an Ames- developed derivative of a program originally developed at 
Bell Helicopter Textron (BUT). It models the XV-15 and could be made 
to model t.h > V-22 and other tilt- rotorcraf t as well. Future effort 
will be directed toward integrating other simulations with TRENDS. 

3. 4. 2.1 GTRSIM. This simulation is capable of finding trim conditions and 
displaying control responses (among other things) as functions of 
specified nudel parameters, control inputs, and flight conditions 
for the XV-15. An interface has been made with TRENDS so that the 
analyst can conveniently access flight conditions and control-position 
time-histories from the XV-15 database to use as inputs to GTRSIM. 

The analyst may then run GTRSIM and store the results for comparison 
with flight -test results. A correspondence has been made between 
simulation-variable mnemonics and flight -test itemcodes, 
including differences in units between the two data sources. 
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3.4.3 


DATAMAP 


DATAMAP, "Data from Aeromechanics Test and Ana 1 yti cs- -Management 
and Analysis Package,” (Ref. 2) is a powerful and elegant tool for 
analyzing rotoreraft test time-history data. Originally developed 
for the Army by BHT , DATAMAP has been modified and improved 
at Ames. Some of its capabilities are duplicated in TRENDS (e.g. t 
spectral analysis, convolution filtering, cycle averaging), but it 
has many more analytical capabilities. An interface has been provided 
between TRENDS and DATAMAP to enable DATAMAP to access data from TRENDS 
databases so that serious analysts can use TRENDS to locate data 
regions of interest, then move to DATAMAP for detailed investigations. 

3. 4. 3.1 Capabilities of DATAMAP. A brief list of DATAMAP ’ s features follows. 


ANALYSIS OPTIONS 


Amp] it tide Spect ra 
Harmonic Analysis 
Digital Filtering 
Moving-Block Damping 
Cycle Averaging 
Min/Max Analysis 
Acoustic Analyses 

Perceived Noise-Level 
Narrow-band Analysis 
Octave Analysis 
Third-Octave Analysis 
A , B , C , D Network Integration 


St.ochast ic Process Analyses 
Frequency Response Function 
Coherence Function 
An to- spectral Density 
Auto-co t re lat ion 
Cros s -co r re la t ion 
Cross -spec t ral Density 
Basic Statistical Analyses 
Mean 
Variance 

Standard Deviation 

Chi- square Test tor Normal 


DERIVED 

PARAMETERS 

True Airspeed 

Blade 

Rotor Azimuth 

Blade 

Rotor RPM 

Blade 

Shaft Horsepower 

B lade 

Shaft Thrust Coefficient 

Blade 

Shaft Torque Coefficient 

Blade 

Density Altitude 

Blade 


Static Pressure Coefficient 
Normal. Force Coefficient 
Chordwise Force Coefficient 
Pitidiing Moment Coefficient 
Displ acement 
Local Flow Magnitude 
Local Flow Direction 


X-Y Plots: 


Contour Plots: 
Surface Plots: 
General : 


GRAPHICAL FEATURES 

Multiple curves on one plot (see figure 3.10) 

Linear or log scales in either direction 
Small data windows can he selected 

Tektronix cursor can he accessed to measure points 
Rectangular or cylindrical format 

Interval, initial level, density are all selectable 
Rectangular or cylindrical format 
Surface may he viewed from any angle 
Conversion of dependent variable units 
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Figure 3.10 Plot Examples from DATAMAP. 




Section IV 


DATABASE MANAGEMENT 

4.0 DATABASE MANAGEMENT INTRODUCTION 

This section deals with acquiring, storing and maintaining flight data 
in the TRENDS database. The TRENDS philosophy is that the Database 
Manager is in charge of these tasks, so that the flight test engineer, 
analyst, or project manager is free of these responsibilities. 

In our system the Database Manager is tasked to gather the preprocessed 
digital tapes from the flight- test center; input the correct parameters 
per test point: for filtering and decimation; enter and reformat the 
data into the TRENDS format; compute the derived parameter quantities 
and check the data validity. These steps are semiautomat ical ly 
performed by using the database management menu; once the parameter 
sets and counters have been decided upon, most of the processing is 
automatic. Validity checks are automatic, but if bad data shows up, 
the Database Manager must look at the data plots individually. The 
connection between the database management software and the accessing 
software of TRENDS is illustrated in figure 4.1. Descriptions of 
menus, menu items and solutions to problems involving database 
management will be addressed in this section. 


4.1 DATABASE MANAGEMENT MENUS 

Database management menus, similar to the dat a-accessing menu of TRENDS 
have been developed to integrate the database management tasks. 

Separate menus exist for the XV-15 and UH-60 database management 
functions because the procedures differ significantly. Future efforts 
will be undertaken to investigate commonalities in the processes and 
to develop an integrated database management menu. 
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Control by 
Database 
Manager 




Figure 4.1 Relationship Between Database Managing 
Software and Accessing Software 
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4.1.1 


XV- 15 Database Management Menu 


The database Management menu for the XV-15 database is 


Flight Data Input. 


Display Files Summarize 


FLIGHT DESCRIPTIONS 
TEST-POINT NARRATIVE 
DATA REQUEST 
Ml UMAX DATA 
DERIVED DATA 
GROSS WEIGHTS 
TIME-HISTORY DATA 
SET DIRECTORY 
HELP 
EXIT 


CHECK T-H 
VIEW MMC 
KEY FILE 
CTRCAT 
THFCAT 
ICS BY CTR 
WORDSCAN 
I TEMDEFS 
SEARCH 


FSTATUS 
CONSISTENCY 
SUMMAR1 ZE 
BATCH CHECK 
REPORT 

VALIDITY CHECKS 

SCREEN 

TRENDS 

TMPTRENDS 


Data Handling 


COPY 

REPAIR 

DELETE 

INPUT LIST 

TAPE LIST 

DESPIKE 

FILTER 

GROUPS 

NOMINALS 


4 . 1 . 1.1 Menu Items. The functions of the menu items ate 

Description of Keyword 
********************** 


Key wo L'd 
* * * * * * * 


Flight Data input 


FLIGHT DESCR" PTIONS 

test-point Narrative 

DATA REQUEST 
M1NMAX DATA 
DERIVED DATA 
GROSS weight; 
TIME-HISTORY DATA 
SET DIRECTOR { 

HELP 

EXIT 


Enter descriptions for each flight 
Enter a short description for each test-point 
Display or enter requests for T-H data by flight 
Reformat, the Min/Max list file produced on FOX VAX 
Calculate and store additional Min/Max data 
Enter initial gross weight and center of gravity 
Process data from FOX-produced compressor tapes 
Set aircraft tali number: change file locations 
Display purpose of menu items 
Return to VMS 


Display File Contents 


CHECK T- II 
VIEW MMC 
KEY FILE 
CTRCAT 
THFCAT 
ICS BY CTR 
WORDSCAN 
ITEMDEFS 
SEARCH 


Display contents of individual T-H files--one line/cti 
Display contents of Min/Max files--one line/counter 
Display contents erf FLTCTRxxx . KEY flies 
Display contents of COUNTER .CAT--one line/counter 
Display contents of THF1LES . CAT 
Display contents of COUNTERS . xxx files 

Call WORDSCAN to search / dispi ay counter descriptions 
Call GR0UP1TEM ter display /search item definitions 
Seare:h values in Min/Max tiles 
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Summarize 


FSTATUS 

CONSISTENCY 

SUMMARIZE 

BATCH CHECK 
REPORT 

VALIDITY CHECKS 
SCREEN 
TRENDS 
TMPTRENDS 


Data Handling 


COPY 
REPAIR 
DELETE 
INPUT LIST 

TAPE LIST 
DESPIKE 


FILTER 

GROUPS 

NOMINALS 


Display by flight total counters by data group 

Tally and display counters per group for all flights 
Display status of data and support files by flight 
Summarize the available data in the database for a 
given flight 

Create and submit command file to check database status 
Produce a printable report file 

Include summary of contents and storage of the database 
Compile and process "Summary ot Data Spikes” 

Pinpoint anomalies of data values for further analysis 
Test, the value of data points (from Min/Max files) 

against, a standard list of boundary values (NUM1NALS) 
Call TRENDS and leave this utility, pointing 
to data in the XV-15 TRENDS database 
Call TRENDS and leave this utility, pointing to 
processing location ot the data 


Copy T-H counters from elsewhere by flight or counter 
Correct or alter values for data in the database 
Delete T-H flights or counters from the database 
Display/edit itemcode lists + filter freq. t decimation 
Read and modify files used by the DCMPRS program 
Display / edit list of tapes with CCF Library VSNs 
Perform search for spikes on raw data files 
Replace data values and write to another f i le 
Use the convolution filter on specified files of data 
Display / search items by groups 

Display, search, or modify a standard list of normal 
limits of valid data values lor selected itemcodes 
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4.1.2 


Ufl-60 Database Management Menu 


The database management menu for the UH-60 database is 


Flight Data Input 


Con trol /Ed it 


Da tabase 


Ut il j t ies 


FLIGHT DESCRIPTIONS 
TEST-POINT NARRATIVE 
NUMERICAL DATA 
TAPE-READ 
LIST ME S , E U FILES 


HOT LIST 
DEFINE ITEMS 
HELP 

COMPRESS 

EXIT 


FSTATUS 

1TEMDEFS 

WORDSCAN 

TRENDS 

INSPECT 


SCAN 

COPY 

DELETE 

MASK 


4. 1.2.1 Menu Items. The purpose of each of these menu items is 


FLIGHT DESCRIPTIONS Enter flight description data (BASKER) 
TEST-POINT NARRATIVE Enter test -point descriptions (INPCOM) 

NUMERICAL DATA Run FILLER to reformat AEFA data for TRENDS 

TAPE-READ Tape-to-disk commands to load AEFA data on NEP 

LIST ME S , E _J FILES Display contents of MES748fff.DAT and EUfff.DAT 


HOT LIST 
DEFINE ITE4S 
HELP 

COMPRESS 

EXIT 


Enter items, filter, decimation for T-H storage 
Enter item-descriptive data (FILLDINFO) 

Display purpose of menu items 
Compress the ITH files 
Return to VMS 


FSTATUS 

ITEMDEFS 

WORDSCAN 

TRENDS 

INSPECT 


Display status of suppnt t files in 1 lie database 
Cali ITEMDEFS to display / search item definitions 
Call WORDSCAN to search /display counter descriptions 
Call TRENDS and leave this utility 
Display contents of specified *.TIM files 


SCAN 

COPY 

DELETE 

MASK 


Display T-H counters stored for a fl Ight or counter 
Copy T-H counters elsewhere for a flight or counter 
Delete T-H flights or counters from the database 
Comment out specified T-H flights or counters 
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4.2 


INSTALLING DATA INTO TRENDS 


TRENDS databases are made up of selected groups of parameters on the 
basis of each test point. Decisions have to be made by the Flight Test 
Director or his assistants as to which data (of those available) are to 
be included in the database. It is during this selection process that 
the first major data compression is performed. The quality of the 
data has to be monitored and steps have to be taken to correct problems 
where possible and exclude bad or misleading information from the 
database. Derived data to be accessed from TRENDS (e.g., Min/Max 
statistics, nonrecor ded-but.-der ivable standard measures, harmonics) 
must be computed and stored. All of these tasks fall under the 
function of installing data into the database. 

4.2.1 Formats and Media 

The media on which data come to TRENDS include magnetic tapes, disk 
files, and printouts (or typed or handwritten pages). The most common 
source is magnetic tape. Tapes come in several formats, among which 
the following have been used: 

1. Compressor tapes from ARC (tagged integers) 

2. Compressor tapes from AEFA (tagged floating point) 

3. RTM 45 tapes from Crows Landing (positional integers) 

4. Be li Standard-label (positional integers) 

a. t ime- histories 

b. harmonic time-histories 

c. Min/Max-per-tev 

5. Ames /Bell flight logs (ASCII descriptions). 

Some of the data arrive as disk files: 

1. Engineering Data Files (EDFs) (positional, floating point) 

2. Min/Max listing tiles from 0F1 (formatted floating point) 

3. Wind tunnel data for HARP and BV360 (formatted floating point) 

4. 2. 1.1 Reformat t ing Programs. A genetic program for reformatting has not yet 
gppfi implemented for all data formats, although this rs desirable. In 
addition to reformatting the time-history data, reformatting programs 
perform other auxiliary tasks, such as deriving unmeasured parameters, 
filtering, decimating, computing Min/Max statistics, etc. Many of the 
processes are duplicated for each reformatting program, which in 
hindsight is a poor practice because of the upkeep required for one 
program versus that for many, but the programmer is sometimes seduced 
into nonop timal choices when trying to develop software rapidly. 

4. 2. 1.2 Processing Time. Compressor-tape processing time, even on a VAX 8650, 
is significant. The following computation is a guide for the XV-15: 

CFU time ( sec ) = (10 + 1.5 x items) x counters 

or 

1 hour of CPU time > for 90 parameters and 25 counters 
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where the counters are from 15-20 sec long, 
100 samples/sec and where "items" represents 
selected for stotage as time-histories. 


the average sample rate is 
the number of parameters 


4. 2. 1.3 


Prompting Prof rams. Some portions of a TRENDS database (in particular, 
the narrative portions) are entered from printed sheets ^someone who 
types the date in at a keyboard. The data are stored in TRENDS in 
binary, keyed- access files which cannot be changed with the system 
editor. Prompt ing programs (in particular, BASKER for < et- a e ^ 
data and 1NPCOM for test-point descript ions) are provided via database 
management menus to assist the data-entry person m the task of filling 
each field in the proper format. Narrative information is important 
the TRENDS database; hence, good tools for data entry increase the 
likelihood that the narrative information will be entered properly. 


4.2.2 


Data Storage Capacity Considerations 

An important practice that not only improves data compression, hut is 
implicit, in tie rapid processing of flight data, is the use of e 
prime-data bit and counter reference point in aircraft data acquisit on 
systems. Implemented in the cockpit of each XV-15 aircraft is a push- 
button which the pilot presses when he is ready to take his test-point 
data. Upon pushing the button, a bit (the ’’prime-data" hit) is set 
high in the data stream. When the button is pressed again the 
prime-data bit drops low and a test point counter (CNTR) , which is a 
separate digital word in the data stream, is incremented. Hence, 
onboard the aircraft in real time both the prime test period and 
counter numbers are automatically recorded in the data stream. The 
counter number thus identifies the prime-data time interval of 
interest. This interval, called a burst, run, maneuver, or test point 
by different people, is usually caiLed a counter in TRENDS vernacular. 
The flight data, including the prime-data bit and counter number, ate 
telemetered town to the ground test facility and output to stripchart 
time-tick per recorders, where test engineers monitor the test’s 
progress. II the test director feels that a test-point is unsatis- 
factory, he tan ask that it be repeated, identifying it by the counter 
number. The counter number and the prime-data hit are both used m 
post-flight processing to locate intervals of interest in the data 
stream. When the prime data bit and counter number are available, 
time-of-day hounds do not have to he specified to identify the data 
interval of . nterest. A list of bad test points to be skipped dur ing 
post-flight processing is given to the ground data center immediately 
after each t.ight. TRENDS uses the counter number to key aLl of its 
test-point data, thereby relating test-point narrative to all types of 
numerical da a. 


Not all of tie flight-test data from a large project can be stored for 
access by TRENDS users. Bad counters and non-prime data have not been 
included, for example. Because of the high data-acquis ition rates (up 
to 500 samples/ sec for the XV-15 and 2000 samples/sec for upcoming 
UH-60 tests), the additional measures discussed below ate taken to 
further reduce data-storage requirements. 
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4. 2. 2.1 Counter Selection. Not all of the counters (test points) which are 
recorded in tests are included in the databases. If problems arise 
in instrumentation, data reduction, or test procedures to negate the 
value of a test point, or if a test point is judged to have no value 
relative to test, objectives, it. will not be included in the database. 
Decisions about what is to be included are made by flight-test engineers 
who are familiar with the test objectives and test results. For the 
XV-15 case, these engineers are provided with a list, of the counters 
(with descriptions) as a file on the VAX. They edit the file to form a 
request specifying which counters and time-history groups are to he 
included in the base. Database management personnel then fill the 
database according to the request. 

4. 2. 2. 2 Groups. One means of reducing storage requirements is by definition 
and selective storage of time-history groups. Of the 350-odd para- 
meters usually recorded for XV-15 tests at Ames, only about 90 are 

of general interest as accessible time-histories in TRENDS. These are 
the "performance" or "handling qualities" parameters such as airspeed, 
stick positions, etc:. For some test points, not even these need be 
stored as time-histories because the Min/Max statistics provide enough 
information to satisfy the test objectives. For other test points, 
different groups of parameters are important to save, depending on the 
particular objectives associated with the flight and test, point. 

The research engineers were consulted to determine which groups should 
be established, the data items making up each group, and appropriate 
filter cutoff frequencies and sampling (decimation) rates. 

The following groupings have been defined for the XV-15 database: 

ITEM CODE GROUPS time-histORY FILE DESCRIPTION 


AEROELASTIC FILTERED. FULL CNTR , 26 items 

CONVERSION UNFILTERED. FULL CNTR, 23 items 

HANDLING QUALITIES FILTERED, FULL CNTR, 70 items 
HARMONICS UNFILTERED, 1000 PTS/CNTR, ABFMS 

MANEUVERS FILTERED, FULL CNTR, 88 items 

SPECIAL AEROELASTIC UNFILTERED, FULL CNTR. 10 items 
SPECTRALS UNFILTERED, 1000 PTS/CNTR, ABFMS 

TRANSFER FUNCTION UNFILTERED, FULL CNTR, 13 items 

The XV-15 groups are defined in greater detail in appendix C. 

A new concept, the "HOT-LIST" concept, was implemented in February 1987 
to enable the flight-test director to change the parameters to he stored, 
their filter cut.off f requenc ies , and their sampling rates on a flight- 
by-f light or counter-by-counter basis as the database is filled. This 
concept has been implemented only for use with the UH-60 database. 

4. 2. 2. 3 Integer Storage. One means of data compression used by TRENDS is to 
store ail time-history data as scaled 2 — byte (16 — bit) integers 
as opposed to 4-byte floating-point engineering-unit values. Most 
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of the data are acquired with only 12 bits (or fewer) of precision 
anyway, so no information is lost by limiting the stored precision to 
16 bits. Eng nee r ing-uni t scaling is applied when the information is 
retrieved for use in TRENDS. Scales and biases are stored along with 
the integer data. This storage technique essentially doubles the 
storage capacity of the given disk space over that of floating-point 
storage. The trade-off is a small penalty in computer time to float 
and scale the data. When the input source is in calibrated floating- 
point foLm. a:; it is with UH-60 data from AEFA, TRENDS determines 
the range of data for each sensor and counter, then derives scales 
and biases which will serve to rescale the data when they are stored as 
2-byte intege :s . 

4 . 2. 2. 4 Filtering and Decimation. Another method of data compression used 
by TRENDS is he filtering and decimation of some time-histories 
before they ace stored in the database. The convolution filter is 
applied to specified parameter time-histories, then only every 
nth sample of the fiJtered time-history is stored. The 
determination of needed bandwidth and sampling rate is made by 
knowledgeable engineers. The lower plot in figure 4.2 shows the 
filtered rept ?sentation of the raw data shown in the upper plot. 

The effective time interval between samples is stored as part of 
the data. Sy urhroniza t ion of the data for two or more time-series 
being cross-plotted or used together in formulas is accomplished in 
TLMEHTST by i it e r polat ion of less-frequent ly sampled series to the 
sample times )f more- f requent ly sampled data. 

4. 2. 2. 5 Series Truncation. Still another means of compression used by TRENDS 
is the truncation of certain time-series before they are stored in the 
database. Th a primary use of many recorded parameters (e.g., accel- 
eration or be iding moment) is to measure their frequency content. 

The anaLyst wants to know this information relative to an interval 
of steady flight at some particular flight condition, so it is 
useless to stare the data across a transient pait of the test point. 

A short burst of data is all the analyst wants, so it is both 
economical ani reasonable to truncate the data to a short I ime inter- 
val. In the :ase of UH-60 data, a "cut-and - save " process is used to 
extract a short interval of the most useful data from the longer 
recorded test point, for which data are available. This interval is 
determined by looking at TRENDS plots of certain low- f i equency 
parameters tenpotarily stored tor the full counter. 

4. 2. 2. 6 Rotor Rev Averaging. Pressure data from upcoming UH-60 tests will be 
recorded at 2000 samples per second, generating big storage problems. 

It is anticipated that these data will be compressed by averaging three 
or more rotor revs together to generate one averaged rotor rev of 
pressure data, hence significantly cumpres s ing the data to be stored. 



4.2.3 


Data Quality 


Thpre are always problems with real test data. Instrumentation .is 
imperfect. Measurements are imperfect. Time-code data often contain 
anomalies which affect the processing of all test data. Data reduction 
is prone to errors. Good data differ from bad data only in the degree 
of imperfection. To avoid including "bad" data in the database, either 
the computer or a knowledgeable engineer must make a judgement. The 
problems of database management concerning the quality of test data are 

1. How can bad data lie detected? 

2. How can had time code data he detected? 

3. Once detected, how can bad data be corrected? 

4. 2. 3.1 Checking Bad Data. Given the time, tools, and interest, a knowledgeable 
aeronautical engineer can look th rough flight -test results and locate 
most of the problems with the data. We would Like to have computer 
software which could do the same tiling, but we have not yet succeeded. 
Users are encouraged to report suspicious data to the Database Manager 
so that it can be corrected, flagged, or deleted. Users are also 
reminded that they are looking at real test data in TRENDS. 

Certain gross checks are made automatically by the database management 
software of TRENDS. For example, the XV-15 pylon angle is limited to 
the range of about 0 to about 95 degrees, so software can flag a prob- 
lem if this parameter measures, say, 234 degrees. If the problem turns 
out to be a bad bias value, this can be corrected. Such checks are not 
generic, but are application- specif ic . Another check made by TRENDS is 
to monitor the change between time-history samples (a slope check) and 
report instances when such changes exceed preset bounds. When the 
hounds are exceeded, raw data are stored (even if storage of raw data 
had not been requested) for later plotting and investigation. Band- 
edge problems can also be detected and flagged automatically. Problems 
which persist are brought to the attention of the flight-test and 
instrumentation engineers . 

The band-edge problem shown in the upper plot of figure 4.2 was caused 
by an improper transducer bias on the pilot’s g-load signal (XV-15 
itemcode A019). The problem was detected during automatic data proces- 
sing and reported to instrumentation personnel for correction. The 
lower plot shows the filtered version of the data in the upper plot. 

This version, derived using the convolution filter and a cut-off 
frequency of 2 Hz, does not exhibit the band-edge problem. 

4. 2. 3. 2 Despiking Data. TRENDS* database management software includes provi- 
sion for despiking time-histories and then for recomputing derived 
statistics and f ii t ered-decimated time-histories from the despiked 
data. Single-point spikes (i.e., wild points, outliers) and some other 
errors which can be detected can he repLaced by interpolating between 
the wild point’s neighbors. Figure 4.3 illustrates a time-series with 
spikes (the upper plot, autoscaled) and the same time-series with the 
spikes removed automatically. 
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TEST XV-15 TILT ROTOR R/C 703 

FLT 228:RERO,LOW SPEED, CONTROL EV 
OTR 13066s LIFT TO IGE HOVER RR ON 




TIME IN SECONDS 

Figure 4.2 Band-Edging and Filtering Example 
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TEST XV-15 TILT ROTOR R/C 703 
FLT 228:AERO,LOH SPEED, CONTROL EV 
CTR 13110 s 3/4' FIFT STEP 5CR5 OFF 
8 



0 5 10 15 20 

TIME IN SECONDS 


Figure 4-3. Example of Despike Program 
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4. 2. 3. 3 Data CrediM.l.ty . In the early days of TRENDS’ development, users 
and potential users were not. confident that the database would give 
them correct answers. Those XV-15 engineers had some degree of 
confidence (justified or not) in the printed Min/Max statistical 
reports provided to them by the Ames Ground Data Center (Code OFT), 
because the reports compared adequately with stripcharts which were 
generated during the flight. The statistical reports were ASCII files 
from which da a could he extracted tor inclusion in the database and 
the reports wore usually available before time-history tapes could be 
obtained and processed to derive the Min/Max statistics. These 
ASCII files wore se let' ted as the source of Min/Max stat istical data 
for TRENDS primarily because of their availability. However, a side 
benefit of their use was soon realized by the TRENDS managers when we 
saw the user community confidence in TRENDS rapidly increase because 
the TRENDS vaLues were indeed the same as in the original printouts. 

4. 2. 3. 4 Time Code Problems. Although the aircraft time code generator is not 
a prime consideration in the way that TRENDS stores and accesses data, 
it cannot be neglected. In our dat a-acquis it ion system at Ames, that 
part of the time code which should logically contain days contains the 
counter number instead. Although it is less likely to happen than a 
glitch in the seconds word (which changes more rapidly), an incorrect 
counter sequence number caused by a time anomaly affects the unpacking 
of all data. This can cause data to be stored in the wrong location 
and it can wr j ak havoc with any automat ic - process 1 ng logic. We have 
no general soLution to this problem, but it is mentioned here because 
a significant effort can be required to solve such problems as they 
come along. It is useiul to have counter number imbedded in the time 
code, because time code is telemetered to tdie gLound and the counter 
number can th?n he used to identify data regions on the strip charts. 

It may be not?d that data are stored not on the basis of time, but on 
the basis of sample rate in the data-acqu is it ion system, since the rate 
is more reliable. Farameter files in TRENDS define what the sample 
rate is for each parameter (e.g. 251 samples / sec: ) , so samples ate 
separated in time by the reciprocal of the sample rate. Time is not 
stored per se in TRENDS files, except for the time of the first sample 
of each parameter. This initial time may differ between parameters 
(i.e., time s<ew), so jt is recorded to enable the synchronization 
needed for cr jss-plott. ing or parameter combination in formulas. 

4. 2. 3. 5 Check Programs. As the size of a database increases, it becomes 
increasing 1 y important to have tools which will automatically pet form 
all of the checks which can be made automatically. Inconsistencies 
creep into the database unavoidably through software oversights, 
source-data problems, etc. It is necessary to have software which will 
locate inconsistencies and other problems so that they may be corrected. 
In particular, summary files must truly summarize, must be complete, 
and must not indicate data which do not exist. Several check programs 
(e.g., CONS IS PNC ) are used in managing TRENDS databases. These are 
documented in the TRENDS Procedures Manual, available from either of 
the authors of this report. 
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4 . 2.4 


Data Derivations 


A TRENDS database includes scalar numerical data of several types as 
well as time-history data. These types include Min/Max statistics, 
parameters derived from those statistics, parameters derived from 
time-histories (e.g., slopes), and harmonic amplitudes and phases. 

To derive these in line as t lie user runs TRENDS is computationally 
inefficient and impossible if the needed time-histories are not stored. 
In addition to the scalars, some time histories are derived for UH-60 
storage and Min /Max-pe r- rev data are derived for loads parameters. 

4. 2. 4.1 Min/Max Statistics. The Min/Max statistical measures for the 

XV- 15 and UH-60 databases were listed in paragraph 3.2.5. The values 
for these measures are obtained by processing time-history data, using 
algorithms which are generally specific to the project and database. 
Sometimes the Min/Max source is an ASCII file of preprocessed values 
rather than a time history. 


4. 2. 4. 2 Derived Parameters. The derived parameters for the XV-15 are 


1 t emcode 

Rescript - ion 

Units 

AILD 

RT AILERON RATE (SLOPE D645) 

DEG/S 

ALFD 

ANGLE OF ATTACK (D008) RATE 

DEG / S 

BETD 

SIDESLIP RATE (SLOPE D007) 

DEG/S 

CDUR 

COUNTER DURATION 

SECOND 

CPXX 

POWER COEFFICIENT 


CRPM 

COMPUTED RPM 

RPM 

c:txx 

THRUST COEFFICIENT 


DNLD 

DOWNLOAD COEFFICIENT 


ETIM 

ELAPSED TIME SINCE ENGINES ON 

MTHMTE 

FLPD 

FLAP ANGLE RATE (SLOPE D617) 

DEG/S 

GOVD 

GOV. LVDT RATE (SLOPE E 7 1 9 ) 

ll S 

GWJW 

GROSS WT USING ADJ FUEL WEIGHT 

LBS 

GWTO 

RAMP GROSS WEIGHT 

LBS 

GWT1 

GROSS WEIGHT, FUEL WT METHOD 

LBS 

GWT2 

GROSS WEIGHT, FUEL FLOW METHOD 

LBS 

HDFT 

DENSITY ALTITUDE 

FEET 

HOOT 

CLIMB/ DESCENT RATE (SLOPE P342) 

FT/ SEC 

IASD 

AIRSPEED RATE (SLOPE P002) 

KNOT/S 

KCAS 

CALIBRATED AIRSPEED 

KNOTS 

KTAS 

TRUE AIRSPEED 

KNOTS 

OATC 

CORRECTED TEMPERATURE 

DEG C 

P1WX 

ADJUSTED HORSEPOWER 

HP 

PCAD 

PYLON CONVERSION RATE 

DEG/S 

PHT.D 

ROLL ANGLE RATE (SLOPE D009) 

DEG/S 

RHPN 

NORMALIZED HP (RSHP/SIGP) 

HP 

RSHP 

ROTOR SHAFT HORSEPOWER 

HP 

SIGP 

DENSITY RATIO 


TDAY 

COUNTER START TIME OF DAY 

MINUTE 

THTD 

PITCH ANGLE RATE (SLOPE D0I0) 

DEG/S 

TOCG 

C.G. FOR RAMP GW 

INCHES 


4-14 


The derived parameters for the UH-60 are 


Mnemonic 

Descript ion 



Itemcode 

AMU 

Advance ratio, derived 

( 

) 

(VOMU) 

CP 

Power coef. (eng. q) , derived 

( 

) 

(CPOO) 

CPROTOR 

MR power coef. (QMR) , derived 

( 

) 

( CPMR) 

CT 

MR thrust coef., derived 

( 

) 

(CTOO ) 

FLAP 

Collected blade flapping 

(Deg 

) 

(FLAP) 

FSCG 

A/C longitudinal c.g., derived 

( Lnches ) 

(FSCG) 

GW 

A/C gross weight, derived 

(Lb 

) 

( FSGW) 

HUB 

Eoom density altitude, derived 

(Ft 

) 

(HDBO) 

HPB 

Boom press, alt. corrected 

(Ft 

) 

( HPBC ) 

HPS 

Ship press . alt. corrected 

(Ft 

) 

( HP SC ) 

LEADLAG 

Corrected blade lead-lag 

(Deg 

) 

( LLAG ) 

MT1P 

Advene ing t ip Mach number 

( 

) 

( VT IP ) 

PITCHC 

Corrected blade pitch 

(Deg 

) 

(FTCH) 

RFFRPM 

Referred main rotor speed 

(RPM 

) 

( VRMR ) 

SHPT 

Combined engine shaft Hp 

(Hp 

) 

( ESHP ) 

VCALB 

Boon calibrated airspeed 

(Kts 

) 

( VCAS ) 

VT 

Cor rected compiled TAS 

( K t s 

) 

( VTRU ) 

VTB 

Boom true airspeed 

(Kts 

) 

( VTAS ) 


4. 2. 4. 3 


Harmonic Amplitude and Phase. The rotorcraft blipper. pulse (R018 for 
the XV-15 and MRTRAZ1 tor the UH-60) is used to define the fundamental 
rotor cycle frequency, then harmonics (6 for XV-15, 15 for UH-60) are 
derived for selected parameters, using software borrowed from DATAHAP . 
The harmonic amplitudes and phases are then stored for access in TRENDS 
via program features HARMONIC, MINMAX, and SEARCH. 


4.2.5 Automatic Updating 

Supporting and summary files, i.e., files which contain summary 
lists of all of the counters, itemcodes, and datatypes available for 
each itemcode, need to be updated as the data are input into the 
database. Because tills was nut done in the original TRENDS system, 
a check of all data in the base was required (as a separate step) 
each time the database was modified. As the size of the database 
increased, this step became very time- intensive . Therefore, it soon 
became necessary to implement routines and procedures tor automatically 
updating the summary and supporting files during the tape- and list- 
processing iterations. These routines are documented in a Procedures 
Manual which is available from either of the authors. 
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4.2.6 


Record Overflow 


The problem of record overflow in a file (because of a fixed maximum 
allowable record length in the computer operating system for keyed- 
access files) made it necessary to have a continuation index indicator 
to connect multiple-record counters. Specifically, only 16,380 bytes 
may be written to one keyed-access record on the VAX/VMS computer 
system, which translates to 8150 integer*2 samples / record (part, of the 
record is taken up by overhead; e.g., counter number, scale, bias, 
start time, samples /sec, number of points). Hence, storage for any 
mainframe parameters (which are sampled at 251 samples/sec) for 
any counter longer than 33 sec requires multiple records. 
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Section V 


TRENDS DESIGN/DEVELOPMENT CONSIDERATIONS 


5.0 TRENDS DESIGN/ DEVELOPMENT 

This section addresses some of the design considerations and 
technical details of the development of TRENDS and gives some of 
the reasons for decisions which were made. 


5.1 TRENDS DEVELOPMENT PHILOSOPHY 

The initial philosophy was that the TRENDS system was to enable 
tionprogr amine rs and noncomputer people to selectively access and see 
all data involved with rotorcraft flight testing. The basic goal was 
to provide not only a user-friendly system, but a complete system. 

5.1.1 User’s Manual 

TRENDS was initially designed NOT to require a user's manual; hence, 
in-line help was a requirement. It is now recommended that the new 
user start with narrative information menu items and then work into 
the plot, options. Our advice to the user is, when in doubt., 
try it. The user can’t hurt the system. The user's manual can he 
useful when looking up parameter names or when running sophisticated 
applications available in the system. Note that full documentation 
of this system results in a large user’s manual which is believed to 
act as a deterrent to using TRENDS for the new user. Most of the key 
features cf TRENDS need little or no documentation. 

5.1.2 Initial System Software Attributes 

Early versions of TRENDS contained most of the basic plotting and 
searching capabilities of the present version, but the user interface 
was less iormai. Unique special features were imbedded into the syntax 
of the system initially; however, because of the pressure from the 
younger engineers, who wanted everything clearly defined, most of this 
kind of ii put has been formalized. It appeared that senior engineers 
were happ) to have any means at ail for displaying the test data and 
didn’t miid a ttial-and-error approach in intei facing with TRENDS. The 
basic problem was in providing the new user with a user-friendly system 
while providing the experienced user with special capabilities, yet not 
complicating the syntax of the input prompts. 


5-1 



5.1.3 


Inc rement al Development Concept 


TRENDS’ development was user-driven from its initial conception. The 
priority for work on the DBMS was to 

1. Get it working, albeit crudely or incompletely; 

2. Respond to users’ gravest complaints or requirements; 

3. Work on extend j ng/ improving system features with 
user-friendliness always in mind. 

As simplistic as this approach appears, it succeeded in making progress 
while maintaining a useful tool. Fortunately, the initial user group 
was small and was tasked to solve real problems, not hypothetical ones; 
hence, only minimal time was spent in trying to justify actions taken 
during the development of TRENDS. Also, the development of this system 
involved only four people, including the authors of this report; lienee, 
system direction and continuity have never been sacrificed during the 
seven years of TRENDS development. The following paragraphs follow the 
chronological order of system development, as driven by user require- 
ments. For a chronological summary, see Appendix A. 

5. 1.3.1 Min/Max Plotting. The first plotting capability required for TRENDS 
was that of plotting one Min/Max item versus another for a specified 
range of counters. To satisfy the requirement without a detailed 
design effort, a somewhat general-purpose plot package was provided 
which allowed the users to input any comments or have any setup that 
they wanted. Plots were tedious to set up with this package. An 
early decision was made to sacrifice the general options a user might 
request and to provide a user-friendly program which would provide 
labeled, scaled plots on the screen within seconds and require minimal 
input specifications. Provision was then made to let the user override 
the labels and scales. Later in the development, the ability for the 
users to put their own titles and comments on the plot was provided 
for, but the great majority of the users were and still are satisfied 
with the titles and scaling that TRENDS provides automatically. It has 
been found that engineers who are actually doing research are primarily 
interested in getting results simply ami quickly. However, new features 
for the TRENDS system are given consideration if they don’t in any way 
complicate the input syntax. 

5. 1.3. 2 Narrative. TRENDS represented a major break with respect to existing 
engineering databases of the time, circa 1982, with the inclusion of 
as much narrative data into the base as possible along with numerical 
data. The intent was to allow a user of the system to know what the 
test was about, and its results, by reading the flight notes and looking 
at numerical or plotted data. In the design of TRENDS, it was felt 
that having narrative data in the system would be very useful; however, 
an appropriate technique for integrating numerical and narrative data 
was not clear initially. It was the decision to use the test-point 
number (counter) along with derived counter sets ( pseudo- flights ) which 
cemented that integration. 
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5 . 1 . 3. 3 


5 . 1 . 3. 4 


5 . 1 . 3. 5 


Psendn-Flight Creation. Providing the user with the 1 Uy to ^arch 
through ail types of data is normally a standard capability 
databases- however, the ability to search and save test points whic 
satisfy the user’s narrative and/or numerical templates semiaut omati- 
cally on tie computer in the user’s home directory was the fj? ature 
which validated the paaudo-f light /derived- flight concept. This concept 
is crucial to TRENDS and its users, since it allows one to 
research on multiple flights easily. Also, pseudo-flight generation 
by the use, personalizes the database to each user a needs: the use s 
in effect build their own databases, but with the unique aspect t 
they need to save only the test-point numbers in directories am 

not the actual data, thereby not increasing storage requirements to 
any significant extent. 

Time-History Plotting. This menu option is the most powetfui one 
in the TRE IDS system, because most analysis involves p lotting o im 
histories TIMEHIST became the home for many options winch cou < e 
thought of as separate functions except for the fact that they are all 
involved with the plotting of data. TIMEHIST allows users to input their 
own functions or to use predefined ones found in a function file. It 
allows all of the mathematical functions, including table lookups, to 
be used by simply typing them in the prompt line. It allows reiterative 
processing of time-history data by executing a process and saving the 
results of that process with a user-defined file name to he used again. 
The data in each case are shown on the screen of the user s terminal. 
Although the integration of so many capabilities _ into one menu item has 
at times been challenged, most users generally like the power his 
single menu item gives them because the prompts can be as simplistic or 
as complicated as the user le quires. 

Formula Evaluation. It was obvious that an analysis system would 
have to have the ability to combine data through mathematical 
operation?. Except for spread-sheet programs, this usually requires 
that a program be modified, recompiled, and relinked each time a new 
function i or subroutine) is to be included. TRENDS was required to 
supply users with any functions they wanted and to he able to generate 
them without having to compile the program. This development was a 
major effort which required formula-parsing and evaluation techniques 
in line w th searching and plotting procedures to evaluate the functions 
without compiling. The end result of this software capability a Lows 
users to not only generate functions (i.e., formulas) and save them 
but also allows users to specify the functions interactively without 
having previously defined the functions. Most user-generated functions 
can he us ul on either statistical or time-history data with no 
distinct! m. The function specification and evaluation capability of 
TRENDS possesses most of the capabilities of FORTRAN formula speci l 
cation. Conditional statements have not yet been enabled. 


5-3 



5. 1.3. 6 User-Friendly Autoplot Setup. Au lop lot. setup, as mentioned previously, 
is a way to significantly reduce the number of user prompts required 
to produce a finished-looking plot on the screen. This is accomplished 
by having special tiles which are automatically accessed each time a 
plot is required. These special files supply project titles, 
test-point descriptions, flight, descriptions, and full descriptions of 
the parameters for the axis labels. Also included in the autoplot 
setup is an automatic scaling algorithm which provides reasonable 
scales. Although any part of the automatic information can easily be 
overridden by the user, most users find the automatic provisions of the 
M1NMAX and TIMEH1ST plot, features to be assets which reduce the time 
required to get meaningful plots. Other features in this autoplot 
setup allow the user to recall previous plot setups which were saved 
under supplied file names, modify those setups if desired, or if it is 
found that a mistake ha 1 ? been made in a difficult setup, to easily 
recall the entire plot setup while still within the plot-dialogue logic 
(even if the setup hasn’t been explicitly saved). 

5.1.4 TRENDX 

It was found necessary t.o generate two versions of the TRENDS database 
operating system in order not to interfere with the user community as 
modification work was being done on the working software. TRENDS 
became the released version while TRENDX was the version of TRENDS 
containing the latest modifications (and made available for acceptance 
testing by some experienced users). 


5.2 DATA PHILOSOPHY 

In TRENDS, data reliability imposes a requirement on the user as well 
as on the database manager. Our aim is t.o do our best to check the 
data before they are installed in the base, hut speed is of the essence 
in this decision; hence, if users finds data they think are bad, they 
should notify NASA. Not all databases are handled in the same manner 
and there is disagreement among the NASA engineers as to the extent to 
which flight data must be certified before making them available to the 
public. In real data systems, errors occur due to bad instrumentation, 
imp roper calibrations, bad sensors, broken wires, etc; hence, these 
types of problems must be considered when using any database. It is 
extremely difficult and expensive to check the validity of all of the 
data in a database consisting of billions of bytes, yet there is con- 
cern that to make uncertified data available might result in some users 
writing reports which are invalid and for which NASA could be blamed. 

Certain checks are made for obvious errors on all data as they come in; 
however, subtle errors may not be found in the data unless the user 
recognizes them. This is where engineering experience is invaluable on 
the part of the user. One must pay a price to allow data to become 
immediately available, and that price is the guaranteed reliability of 
the data. Unlike the XV-15 database, the UH-60 database has been re- 
viewed by knowledgeable engineers specifically to remove bad data. The 
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UH-60 database is relatively small (500 megabytes) and it took over a 
year to certify that it was valid. Yet it you ask those who certified 
the data whether all the data in the UH-60 database are good, their 
answer is that, they are not. certain. How long will it take to validate 
30 gigabytes ol pressure data when they are added to the existing UH-60 
database, and can we wait that long? It. is unclear how certification 
can be run on all UH-60 data without spending years in the process. 

The aim of TRENDS is to interface to users who understand the diffi- 
culty of this problem and are willing to help with it. It is felt that 
users require certified data should use only NASA reports, even if they 
take years to get, rather than to question the usefulness of a system 
which is trying to get data out rapidly. TRENDS represents an experi- 
mental concept of making raw data available to the users for their own 
research. The future of TRENDS may he in question if the user community 
requires that all data be perfect, data. 

5.2.1 On-Line Data 


System speed cf response has always been an important, consideration 
in determining user acceptance of a system; hence, there has always 
been a requirement to provide all data on line within TRENDS (as 
opposed to having to have tapes or disks mounted in order to access 
data of interest). Although we still have storage problems, techno- 
logical improvements in storage, along with data compression, have 
allowed us to achieve a system capability where all pertinent data are 
on line via d.sk storage. Total TRENDS database storage is currently 
about 5 gigabytes. In an attempt to maintain this on-line capability 
in a limited floor space and with limited funding available for storage 
media, NASA has chosen to go to a write-once- read-many (WORM) optical 
disk storage ukebox system to bring on line another 80 gigabytes of 
storage. Although there will be slight delays in the new system as 
compared to the old, it is still expected to be able to provide on-line 
sttuage of a 1 . . data. 

5.2.2 Database Management Considerations 

The details o 5 *' creating and maintaining a flight -test database are 
many and varied. Logistics of acquiring the data irom the source 
must be considered, as must such details as the operational status 
(and ope rat in,» system) of the computers which host the databases. 

Most of these details are abhorrent to aeronautical engineers and 
not of much interest to programmers. Software and procedures must 
be developed :.o automate the process as much as possible. Resource 
contention an 1 database cleanup are examples of the details of 
maintaining a database. 

5. 2. 2.1 System Readiness. The activity of filling the database can block the 
use of the system from the accessing community if some care is not 
taken to avoid this problem. Special measures are taken to avoid 
interference vi th active users during database management operations 
by copying database files to temporary files, modifying the temporary 
files, and then recopying them back into the main database. Changes 
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in file formats must also be made in such a way that the users are 
not taken off line during modification and checkout. 

5. 2. 2. 2 Data Deletion. User-friendly data-de] et ion features which allow new 
data to overwrite old data are important to the database manager. 
Inevitably, some existing data in the database will he found to be 
incorrect. The keyed-access file structure has provided a fairly 
simple means for manipulation (i.e., filling, deleting) of the data 
in the base on a nonchrono.Logical (i.e., nonsequential) basis. That 
is, records may be added, modified, or deleted at any time, without 
concern for which records precede or follow them in the files, thus 
permitting the processing of current flights of interest first, then 
using a back- and- f ii i procedure tu cuinpiete the database. 

5.2.3 Multiple Databases 

The TRENDS system was initially designed to support two separate though 
similar databases for two tilt-rotor flight-test programs. Both of the 
databases used the same set of itemcodes and the same conventions for 
test-point specification, although data-source formats were different. 
The database set was expanded for a short period of time to incorporate 
some data from the RSRA helicopter program. Support of RSRA by TRENDS 
was the first attempt to create and access a completely different 
database. A copy of the existing XV- 15 TRENDS code was made ami 
modified to support the RSRA database. This method was quick and led 
to results in a very short time, but it proved to be a mistake. It 
would have been better to have taken the time to develop the generic 
soitware which would treat the peculiar characteris tries of all of 
the databases with the same generalized code. The fourth database was 
for the Phase I UH-60 flight-test program. This ushered in the first 
attempt to solidify TRENDS into a generic code. A wind tunnel database 
was also added to the system; however, its impact on the original code 
was minimal. Note that the integration of new databases into the 
TRENDS domain has helped to improve TRENDS by making more demands on 
the system, from which new capabilities become available to all users 
of the system for ail databases supported by TRENDS. 

5. 2. A Database Structures 

TRENDS is firmly based on the keyed-access file structure and operating 
method. Most of the numerical data reside in files named by the param- 
eter’s itemcode or mnemonic and keyed by counter number. These files 
reside in directories named for the specific data type they contain. 

For example, the Min/Max statistics for itemcode 1)186 are found in a 
file named D186.MMC which is found (for A/C 703) in a directory named 
[UB703.MMC]. The record in which the Min/Max statistics for counter 
16500 are found is keyed by the integer 14500. The VMS operating sys- 
tem performs must of the overhead in locating the record. This ties 
TRENDS to the operating system, but it takes advantage of system effi- 
ciencies and offers the potential for improvement with system upgrades. 


5-6 


Much of the supporting informat ion, stub as which counters are in a 
given flight, could he found by reading all counter-description files 
for the flight in which the counter is found, but this would take a 
long time and waste both the user’s and the computer’s time. TRENDS 
creates and uses a number of supporting files to store information 
which groups and categorizes other data in TRENDS databases. These 
will be discussed in this section, along with the supporting files 
which augment the numerical data with descriptive information. 

5. 2. 4.1 Keyed Access. The keyed-access file capability provided by DEC 

under the VAX/VMS operating system is perfect for a database management 
system such as TRENDS. If this capability were not available, it 
would have to be synthesized. The keyed-access capability lets one 
retrieve £ record from a random-access (i.e., disk) storage device by 
specifying a NAME or NUMERICAL LABEL for the record. For example, the 
descriptive information for item M143 in keyed-access file ITEMINFO.DAT 
is ret riev ed by ask ing for and reading the record named Ml 43. It is 
not necessary to read each of the records in the file and to test 
it the record which was read was for M143 (a process which would be the 
only recourse if ITEMINFO.DAT were of SEQUENTIAL organization). in the 
past, when databases were stored on magnetic tapes, leading tiles and 
records hud to be read (or, with a priori knowledge of the sought data, 
sk ipped over) to gel. to the information of interest. If ITEMINFO.DAT 
were of indexed-sequent iaL (direct-access) organization, one would have 
to keep a c atalog which assoc iated ML43’s record with a serptenc e number, 
search that catalog to find the appropriate number, and then ask tor 
the record by sequence number. This process would get very c (imp lex 
when new records were added or old ones deleted. With keyed-access 
organizat .on, the VAX/VMS operating system does the bookkeeping for 
you, simplifying the programming of deletions, additions, or replacement 
of record:; . 

It. might he argued that direct, access should he considered over keyed 
access to: data records for which the key is a positive integer such as 
counter number. Not only is this a restrictive condition, hut. direct- 
access files are observed to have two fundamental problems: (1) they 

require fixed-length records (and are, therefore, wasteful for vari- 
able-length such as time-histories) and (2) empty records take up just 
as much s lace as full records, so databases with sparse c ounter 
sequences are very wasteful of space. Keyed-access files can handle 
variable- Length records and they do not leave space-holders for empty 
counters . 


Keyed access is operationally convenient for filling and managing a 
database because the older of filling is of no consequence. That is, 
later (i.?,, higher-numbered) counters may be processed prior to 
earlier (i.e., lower-numbered) counters, 

A very useful feature of key ed- acre s s files .in VAX/VMS is that they 
may also he read sequentially, if desired. In this case, the results 
are ordered in ascending order of the keys (i.e., numerically or alpha- 
betically ascending), providing a simple means for producing a sorted 
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list. A variation of this feature ]ets you first read a particular 
named record and then read sequentially (i.e., ordered) from that 
record onward. This method of reading in data has been used in parts 
of TRENDS to optimize the access in the presence of "look-ahead" system 
disk-reading procedures. 

5. 2. 4. 2 TRENDS File Structures. One must consider many factors when choosing 
a file structure for a database. Some of these factors are: 

1. How will the information from the database be used? 

2. How much data must, he archived? 

3. What are the procedural limitations and constraints? 

The basic keys for databased numerical (e.g., Min/Max or time-history) 
records are (1) item name (itemcode, mnemonic, etc.) and (2) counter 
(test-point identifier). That is, given the data item and test-point 
index, the data record should he identified for retrieval. Of course, 
we assume that the database is given and that item and counter are 
unique within that database. Given the requirements for basic keys, 
there are still many ways t.o structure files in a database. Choices 
for file structures and formats were made early in the design of TRENDS 
and most of those choices have proven to be good. A detailed discus- 
sion of the options may be found in Appendix D. 

5. 2. 4. 3 Supporting Files. The bulk of TRENDS 1 stored information is numerical 
test data from sensors, but. a TRENDS database is completed by another 
kind of information: that found in supporting files. Supporting files 
come in two categories: (1) descriptive files and (2) summary files. 

Descriptive files augment the numerical test data by providing 
narrative support such as item descriptions or project, 1 light and 
test-point descriptions. Summary files enable efficient searching and 
use of the counter-keyed numerical and descriptive files in the base 
by providing precompiled, categorized lists of counters for which 
data exist in the base. Figure 5.1 illustrates the function of these 
supporting files in exercising some key menu items. 

1. Descriptive Files. These files add information to enhance the 

use of the numerical data in TRENDS. They include 

a. CTRDESC.A/C, the counter-description catalog file, keyed 
by counter and containing other count e r- ref e rence 
information such as start /stop times, rotor revs, flight 
number, and data-group availability 

b. ITEMINFO . A/C , the item- in forma H on file for each database, 
keyed by data-item mnemonic and itemcode, containing item 
descript ions , data units , mnemonic / itemcode correspondence , 
and data-group codes 
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MENU ITEMS 


SUPPORTING FILES 



#1. Parameter Descriptions 


ITEMINFO. A/C 


/ FIND 


Descriptive File 


#2. Legal Parameter Names 


ITEMINFO. A/C 


' FIND 


Descriptiue File 


#3. Data Available 

THFILES. A/C 



' FIND 


Summary File 


#4. Data Region 

FLTCTRMAP.A/C 



Summary File 


#5. Counter Descriptions 


CTRDESC. A/C 


Descriptive File 


#6. Flight Descriptions 


FLIGHTS. A/C 


Descriptive File 
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c. FLIGHTS. A/C, the f 1 ight -descr i pt \ on file, keyed hy flight 
number, containing categorized flight-descriptive narrative 
information 

2. Summary Files. These files contain information which allows 
efficient access to the database and which enables display of 
current database status. They include 

a. Fl.TCTRMAP . A/C , the file which contains the catalog of 
counters for each flight, keyed by flight number and used 

to pull up a set of counters when the user asks for a flight 

b. THFILES.A/C, the file which contains the summary of time- 
history data available in the database for a given parameter 
keyed by itemcode or mnemonic and containing a list of the 
counters for which data are stored for each time-history 
data type or group 

c. COUNTERS . XXX , the files for each data type (XXX), keyed by 
counter number and containing a list of the names of the 
parameters for which data are stored for the specified 
counter and data type 


5 . 3 USER-FRIENDLINESS 

User-friendliness was a strong guideline in TRENDS program development. 
Any new program feature was always designed for robustness and ease of 
use. Prompts and required responses were studied carefully to make 
sure they were logical and simple. Because the intended TRENDS users 
are engineers, rather than programmers who can modify software to get 
the desired result (given the time to do it), the user interface had 
to be complete. For example, prompting capabilities had to he 
included for creation of some user-files (e.g., files for PERFPLOT 
and CPR1NT setups), while programmers could be given the format and 
asked to write their own. 

Among the user-friendly features of TRENDS are (1) the capability for 
entry of da ta-manipula t ive formulas (functions) in plot and search 
dialogues, (2) a very simple plot-specification syntax, together with 
the ability to recall and edit stored plot setups, and (3) integration 
of narrative data to support the stored numerical data. 


5. A USER FEEDBACK 

It has been observed that no two users have the same requirements or 
preferences with respect to database or system operations. We have 
tried to satisfy a broad range of users by making studied judgements 
of what is essential, user-friendly and logical. By presenting a 
system which performs useful services with little effort on the part 
of the user, TRENDS has attracted a large community of users. If we 
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had catered to a few particular users, TRENDS wo., Id probably not have 
the follow ng it has. User comments and suggestions are solicited and 
evaluated, but not necessarily followed' (or at least not with the 
priority the user might give the suggestion). Every effort is made to 
provide special software for special requests for capabilities or data 
which are not available in TRENDS or its databases. 


5.5 ANALYSIS TOOLSET 

The accessing part of TRENDS currently consists more than 20,000 lines 
of executable code and over ?oo modules (exclusive of D1SSPLA, 

DATAMAP , GTRSIM, command tiles, help-files, pointer data, etc.), so 
it has became necessary to develop and use computerized tools to 
keep track of software details and dependencies. The use of FORTRAN- 
source-scanning tools and keyed-access sorting techniques to analyze 
and summarize the use of subroutines, commons, files and variables is 
very advantageous when trying to maintain the software of a program 
the size of TRENDS. Appendix E contains a hierarchy chart or calling 
tree of the TRENDS accessing software, produced by the toolset. 


5.6 INSTALLATION OF TRENDS 

TRENDS car be installed on any VAX/VMS system which has the DTSSFLA 
graphics i ackage available. It has been installed at AEFA (with the 
Megatek graphics package) and at MDHC (cm a MicroVAX) , as well as on 
several different VAX nodes at Ames. The source code is written 
entirely in DEC-extended FORTRAN. The disk storage requirements for 
TRENDS (i.e., for the accessing program -- not including the database 
management software) are: 

Source 2000 blocks (1 block = 512 bytes) 

Object 1400 blocks 
Executable 1600 blocks 
Help tiles 1000 blocks. 

TRENDS requires a virtual page count of at least 50,000 to run. 

TRENDS alto provides gateways to the DATAMAP and GTRSIM programs. 
DATAMAP* s executable module occupies about 800 blocks, but the piogram 
requires about 6000 blocks of user disk space to execute when scratch- 
file storage is included. GTRSIM’ s executable module occupies less 
than 600 .locks, but the TRENDS interface routines require another 
3500 blocks (which requirement could be reduced to about 2000 blocks 
with more efficient coding). 

Any questions regarding access to TRENDS or installation at your 
facility ran be addressed to the authors (Bondi at (415) 604-6341 or 
Bjurkman at (415) 964-1844). 
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Section VI 


CONCLUSIONS 

6.0 CONCLUDING RLMARKS 

TRENDS has been used within the FA division at Ames for almost 
seven years as the primary means of archiving and accessing flight 
test data fo - rotorcraft. It has recently begun to he more widely 
applied and used by other Ames organizations and by industry as well 
Its capabilities and potential for extension to a wide variety of 
test data make TRENDS a valuable tool. 

This section concludes with a summary of some of the lessons which 
have been learned during TRENDS’ development and an indication of 
the direction TRENDS might take in the future. 


6.1 LESSONS LEARNED 

In the development of a large database operating system, one hopes to 
learn important iessons which might help someone else in development 
of other database systems. The following items are some we believe to 
be worthy of mention. 

6.1.1 User Impact on the Development of TRENDS 

It has been observed that no two users have quite the same requirements 
or preferences with respect to database or system operations. We have 
tried to satisfy a broad range of users by making studied judgments 
of what is essential, user-friendly and logical. 

You can never satisfy all of your users; therefore, let only the mature 
users drive your software system development. Software development to 
solve hypothetical problems only buys unnecessary complexity and 
produces essentially no useful output tor most of the user community. 

It has been found in working with aeronautical engineers that ALMOST 
meeting the requirement is NOT acceptable to some users. Such users 
turn off the entire system, not just the part where there is a problem. 
All of the extras on the system will not bring them back to it unless 
their essent ial requirements in ALL areas are met . The lesson is that 
you can’t p ease all of the people all of the time, nor some of them 
any t ime . 

6.1.2 Database Evaluation Criteria 

TRENDS has been compared to a file cabinet full of reports and plots. 

It was judged to be valuable only when it could replace most functions 
of the cabinet. TRENDS was accepted by one "hard-sell" engineer 
because : 
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1. TRENDS not only lias all of the plots ami narrative information 
available, lint it allows the user to search through both narrative 
and/or numerical data to group it into data sets (pseudo or 
derived flights). This is not simple with a cabinet system. 

2. Accessing miscellaneous plots from different flights with TRENDS 
is faster with the computer than with a manual system, and 

the presentation of the parameters on the plot can easily be 
altered (unlike the file cabinet plots). 

3. Mathematical functions can be easily and rapidly applied to 
parameters through TRENDS, but hardcopy plots never change. 

4. When any other (including remote) aeronautical engineers need to 
see 1 light data, TRENDS is available to provide it, unlike the 
file cabinet which requires that the cognizant flight-test 
engineer always be available. 

Note: The ability to store the contents of a file cabinet in a computer 
system and provide access to that information as readily as one might 
use a file cabinet is a significant challenge to any systems designer 
and could be considered as a good benchmark of the performance of any 
database system. 

6.1.3 Access to Calibrations 

TRENDS provides access to parameter calibration information (for the 
XV-15 database) as a main-menu item, CALIBS. Even though the test 
data are presented to the user in engineering units, access to the 
calibrations through TRENDS has proven to he a useful capability for 
many users, especially when trying to determine data validity and 
causes of some anomalies. 

6.1.4 Generic Code 

Generic code development is important to the task of maintaining 
system software. This was not appreciated until the complexity of 
the TRENDS code increased to the point where it was impractical to 
maintain three systems which were similar but not identical. 

Whpn generic software was initially implemented into TRENDS for the 
integration of multiple databases on different rotorcraft, it was done 
very late (about 4 yr into the system design). A significant part of 
the problem for the generic code was to accommodate the handling of 
new and longer parameter names, specifically the eight-character 
parameter names used on the UH-60 versus the four-character ones 
, lnit islly used on the XV-15, Each reference to parametei name 
information had to be revamped. It Is felt, that many hugs In the 
system which had already been corrected resurfaced because of this 
necessary code change. A ripple effect of system crashes seemed 
to enter into the TRENDS software as a result of this late generic 
modification. Current thinking is to t.iy to keep all software generic 
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from the cutset; that is, one fix fixes the same problem for all 
databases. Special code development should be negated. In the long 
run this special code will generate mote problems than it is worth. 

If at all possible, do not let the code split. 

The fol loving are some areas where generic code development should be 
cons ide tec : 

6. 1.4.1 Database Vectors. Do not have the location of the database embedded 
in the cote, but rather get it as an input to the program. Initially 
the path tame for the data was embedded in the code, but this created 
two problems ; namely, the program had to be changed if the data were 
relocated, and when software was put on another computer and had to be 
modified Mid recompiled. 

Appendix 1' presents the method used in TRENDS for vectoring to 
a database. 

6.1./, .2 Parameter Names. The logic in a system should not assume a fixed 
length fo:' parameter names, but should treat variable-length names 
in a field long enough to take care of ail likely mnemonic lengths. 

To date, n maximum length of eight characters has proven to be 
sufficient for any TRENDS database. 

6. 1.4. 3 Symbol Table. Symbols for the data parameters should be input from an 
external file rather than be compiled into the software. This permits 
flexihlli y in choosing names, modification of the parameter 
descriptions, and moving from one database to another without compiling. 
TRENDS us?s a file named ITEMINFO which contains one record for each 
item. Records are keyed by the item’s mnemonic (or itemcode) and 
contain descriptions, units, instrumentation group and other data. 

6. 1.4. 4 Help File?. The help which is displayed in response to a query by the 
user should come from input, data files created via the system editor, 
as oppose! to being compiled into data statements in the program. This 
gives flexibility and reduces the effort required when the information 
change s . 

6. 1.4. 5 File Structure. Hake common file structures for similar files in each 
database, e.g., Min/Max statistics files for XV-15 and UH-60 are 
structurally identical even though the UH-60 has more statistical 
measures in each data record. Time-history file structures are 

are identical for all TRENDS databases. 

6. 1.4. 6 Data Types. TRENDS’ time-histories were categorized into data types 
(e.g., *.raw; *.spc; *.aer) for accounting purposes. This proved 
fortunate because it simplified the dispersion of data files onto 
different disks when we ran out of storage on the original disks. The 
initial time-history file format in TRENDS was one file per parameter 
for all flights; the ultimate limitation of such a system would be one 
file filling an entire disk. Before that occurred, however, it would 
be necessary to migrate parameter files onto other disks transparently. 
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A different file format, the DATAMAP and TRENDS (DAT-TH) format, will 
be used in the future to help to alleviate the problem, 

6.1.5 Plotting Generality 

It is better to provide a spec: ial ized plotting format which is easy 
to specify than to provide great generaJ ity and graphics capability. 

The types of plots enabled by TRENDS cover most of the needs of 
Ames engineers. Users can specify non-default labels, scales and 
titles with a little extra effort and can store/recail plot setups 
to avoid re-entering specifications. TRENDS works with a variety of 
different terminals . 

6.1.6 System Response Speed 

User acceptance does depend on the system’s response and system 
response is therefore a key consideration when writing code. Two of 
the techniques used in TRENDS to achieve better response times are 

1. Summary support files, updated automatically during data- fill, 
to eliminate the need to query the whole database to see which 
counters and itemcodes and data types exist 

2. Keyed access to locate the first data in a requested sequence 
and then sequential reads with tests (uses efficiency of 
system luok-ahead algorithms) 

Note: Summary support files are in fact data-redundant ; however, the 
increase in file storage is insignificant relative to the improved 
response of the system. These summary files must be automatically 
updated every time the main database is updated. 

6.1.7 Database Management (DBM) Menu 

Getting data into any database system is not a trivial task; the TRENDS 
system manager therefore decided to approach the problem formally by 
creating a data input menu system by which all data are input into the 
database. To a minor extent, each DBM menu is tailored to each rotor- 
craft’s database. The current TRENDS DBM menu is not complete; how- 
ever, it is being used by database management, personnel at Ames and it 
is felt by the authors to be an asset. Although there was disagree- 
ment about the need for such a menu and its development was given a 
low priority, this type of software is important, and can be critical 
if the program is transferred from one contractor or management team to 
another. This software provides the TRENDS manager with better control 
for supporting his system if he has to introduce a new team to a TRENDS 
data-input task. Finally, this type of software helps experienced 
users avoid mistakes. 

6.1.8 Flight-Test. Support 

TRENDS can be used as a f light- test- support tool, as it was in 
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the Phase I JH-60 tests at AEFA. In this role, the narrative stored 
in TRENDS cai he fresh and accurate and used to document the tes.s. 
Data anomalies can be spotted and instrumentation/ reduction error 
ran he corrected before they permeate the entire test series, 
requirements (such as the need for measured rotor azimuth) can he 
noted and possibly satisfied during the testing. 

6.1.9 Data Quality Considerations 

Concern for data quality imposes a requirement nn the user as well 
as on the database manager. Automatic and spot checks will not 
identify all of the of the errors in the stored data. Users must 
report problems to the database manager for resolution. It is te 
that users who must have completely certified data should use only NA 
reports and that TRENDS users, while they can be reasonably confiden 
in the data stored in the base, should be realistic and watchful. 


6.1.10 Data Storage Considerations 

Disk storage is probably the most important of all considerations for 
flight-test databases. If there are trade-offs between execution time, 
convenience etc. and storage in the design ol a system, the edge must 
be given to minimizing storage. One significant decision in this 
regard led no the storing of all time-history data as two-byte integers 
rather than as floating-point numbers in engineering units; another 
was to stor? only start-time and time increments between samples rather 
than to store time with each measured data sample. 


6.1.11 Time and Tine Offset 

Data samples recorded in a flight-test system are usually recorded at 
regular intervals of time. This makes it acceptable to archive 
only the starting time and the time increment (or equivalently, the 
sampling rate) with each time-history record. Not all time-series 
begin at the same instant, however, and not all time-series for a 
specific aircraft, instrumentation system, and test point have the 
same sampling rate. Therefore, to enable detailed analyses, great 
care must be taken to gather and store the time parameters in the 
right way. In particular, mainframe and subframe offsets must be 
obtained ard stored so that relative phasing of flight parameters 
is preserved. The starting time for XV-15 data was stored in 
s ingle -pre< is ion, floating-point seconds for the tens of thousands 
of test points In the database. The significance of the mantissa 
in the VAX floating-point word is only about 6+ decimal digits, so 
the resolution of the starting time is only about 0.1 sec and 
therefore not very useful in rotor phasing calculations. It would 
have been much better, in retrospect, to have stored the starting 
time in four-byte integer milliseconds or to have stored seconds 
modulo 100 for example. To correct this problem now would require 
reprocessing thousands of magnetic tapes. 
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LASER JUKEBOX CONSIDERATIONS 


In 1990 the TRENDS system will incorporate a 90-gjgabyte laser-optical 
jukebox system because of anticipated requirements for flight-test, data 
storage. The time required to access time-history data will increase 
from what it is currently (on fixed, magnetic diskc), especially when 
the jukebox must change platters (i.e., optical disks) to get to the 
data. It is uncertain at this point whether or not some sort of caching 
scheme will have to be implemented in order to adequately support mul- 
tiple users and/or to improve time-history viewing performance. A 
5 1/9” (disk-diameter) system was selected because it appeared to be 
much more cost-effective (both system and media-wise), than a 12" 
system. The 5 1/9" system requires much less room (less than one 
standard five-drawer file cabinet), uses standard 15-amp, 110-volt power, 
and appears to be less complicated (hence, more reliable, we hope) than 
12" systems. The use of WORM rather then erasable optical disks is 
based on the archival character of the data to Ire stored and the WORM’s 
high reliability, which does not require tape backup. 

The system being acquired is a 90-gigahyt.e Mitsubishi Laser Optical 
Jukebox library system (Model MW-5G1-B9) with four (9) optical drives 
(model MW5D1 ) , and two (2) KOM SCSI/UNIBUS controllers interfacing with 
KOM Optiserver (Version 2.x) and Optifile II software for the VAX 
computer . 


6.3 FUTURE TRENDS FEATURES 

One piece of information which is not included in TRENDS (but which 
would Ire helpful) is the location of all transducers (i.e. sensors) 
on the rotorcraft . To provide an accurate computer-graphic picture is 
complex and in some instances would require a number of drawings with 
enlarged sections. This feature is being considered as an additional 
desirable capability. 

The further integration of mathematical model simulations into TRENDS 
is high on the priority list for future expansion. Some of the 
simulations being considered for integration are CAMRAD, CL81, GENHEL, 
TILTWING and NASTRAN. 


6.9 FUTURE OF TRENDS 

Finally, the biggest concern is how to support TRENDS through the years 
as NASA organizations change, user support changes, funding shortages 
occur, computer operating systems change, and computer mainframes 
change. Maintenance of such a system requires perseverance, 
vigilance, and concern, but its value as a tool for the engineer is 
well worth the effort required to to provide it. 
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Glossary 


A/C 

A/C 702,703 
AEFA 

AMA 

Ames 

ARC 

Bell, BHT 
BV- 360 
CCF 
CDC 

Compressor tape 
Counter 

Crows Landing 

Data item 

Database 

Data region 

DATAMAP 

DAT-TH 

DBMS 

DCMPRS 


Ai rcraf t. 

Tie two XV- 15 aircraft (702 and 703 are the tail numbers) 

Aviation Engineering Flight Agency, U.S. Army flight-test 
facility at Edwards AFB , CA 

Analytical Mechanics Associates, Inc., Mountain View, CA 
NnSA Ames Research Center, Moffett Field, CA 
Acronym for Ames Research Center 
Bell Helicopter Textron 

A helicopter made by Boeing-Vertol of Philadelphia. PA 
Central Computer Facility at Ames 

Control Data Corporation, computer manufacturer 

A digital test-data tape format used at Ames 

A number which identifies a specific test point (sometimes 
used to mean the test point itself) 

p ASA flight-test facility at the Crows Landing Naval 
Auxiliary Landing Field 

A parameter, variable or channel for which data may 
fxist in a database 

A collection of numerical and descriptive information 
accessible via TRENDS 

"he flights, pseudo-flights or counters of interest 
when exercising a TRENDS search or display feature 

a rotorcraft-data analysis program built for the Army 
by Beil Helicopter Textron (Data from Aeromechanics Test 
and Analytics -- Management and Analysis Package) 

lew DATAMAP and TRENDS time-history file format 

DataBase Management System 

\ TRENDS database management program for reformatting 
compressor- format tapes or disks 
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DCS 


Derived Counter Set (See Pseudo- f 1 ight ) 


DEC 

Derived items 

DISSPLA 

DNW 

DTF 

EDF 

FA 

FFT 

Flight 

FOX, FOX 4 
Generic code 
Gigabyte 
GTRSIM 

Harmonics 

HARP 

In-line function 
I temeode 


Digital Equipment Corporation of Maynard, Mass., maker 
of the VAX computers 

Data items not directly measured, but derived from other 
data items for storage in a TRENDS database 

A graphics package, product of ISSCO, Inc. of San Diego, CA 
and widely used on VAXs at Ames 

Deutsch/ Nederland Wind tunnel facility in The Netherlands 

Data Transfer File format acceptable to DATAMAP 

Engineering Data File, a data format produced by the 
Ground Data Center at Ames 

Aircraft Technology Division at Ames ( FAF and FAR 
branches are principal TRENDS users) 

Fast Fourier Transform, a method for determining the 
spectral (frequency) characteristics of a signal from 
a time series representation 

An identifiable portion of a test project, such as one 

day s test results or a run (batch) of windtunnel test points 

VAX computers at the Ground Data Center at Ames 

TRENDS software which applies to all TRENDS databases 

One billion bytes 

The Generic Tilt -Rotor Simulation program, developed by 
Bell Helicopter Textron and modified by STI 

Fourier coefficients which synthesize a signal’s 
frequency characteristics at multiples of a fundamental 
frequency (i.e., the rotor rev rate) 

A wind-tunnel database for the Hughes Advanced Rotor Program 
(now an MDHC program) 

A defined formula or function evaluated during execution of 
TRENDS 

A 4-charact.er code which identifies a flat a item or parameter 
(the original XV-15 itemcodes had one letter and three numbers 
such as Ml 4 3 or P002) (See also Mnemonic) 
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Keyed access 


/ file-access att 
record of data is 
access, where the 


t - Unite, available on VAX/VMS, by 
identified by name (as opposed 
record is identified by sequenc 


which a 
to direct 
e number) 


Laser-op tical 
LOTUS 1-2-3 

MDHC 

Menu item 
Min /Max 


MMC , MMR 
Mnemonic 


a new technology for data storage 

A software product (spreadsheet) of Lotus Development 
Corporation of Cambridge, MA 

McDonnell -Douglas Helicopter Company in Mesa, AZ 


One of the TRENDS features invocable via the TRENDS menu 


Data-item statistics based on 
values observed on each rotor 
genetically to mean scalar or 

Min/Max per counter, Min/Max 

A brief name for a data item, 
in TRENDS to 8 characters (See 


the minimum and maximum 
revolution (sometimes used 
non- 1 iine-his tory measures) 

per rev data types 

sur ’h as LONGSTK , limited 
also It.emeode ) 


NEP 


Designation for the Neptune VAX computer at Ames 


OF I 


On- 1 ine 


The branch for the Ground Data Center at Ames 


Ready for immediate access (an on-line database 
no special tape mounts or special processing to 
access to stored data by the uset) 


requires 

enable 


PC 

Performance 


Personal computer (as opposed to a mainframe computer) 

Data items or test results relating to the performance 
of the test vehicle 


Pseudo-flight 

Rev 

RSRA 


A co 


llect ion of related test points constructed by the user 


One revolution of the rotor of a rotorcraft 


Rotor Systems Research Aircraft 
built by Sikorsky Helicopter of 
by Ames 


a modifiable rotorcraft 
Stratford, C-N and operated 


RTM tapes 
STI 

Supporting files 


Real-Time-Merge digital data tape format used at Ames 
Systems Technology, Inc. of Mountain View, CA 

Elements of a TRENDS database which do not contain recorded 
or deiived test data, but aid in the implementation of the 
system 
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Summary files 


Elements nf a TRENDS database which summarize various aspects 
of the database 


i ARLES 


lest point 
Test - point index 
Time -history 

T-H 

I PENDS 

. 11-6 0 

Vfi.X 

VMS 
VSN 
T)RM 
: V - 15 


The name of a Tektronix (and later VAX) Basic program which 
was used at Ames before TRENDS to plot and list XV-15 
Min /Max data 

An identified portion of a test for which data are collected 

A number which identifies a specific test point 

A set of data sampled at a series of sequential time points 
to show time variation 

Abbreviation for time-history 

The TRENDS interactive database operating system 
(the acronym originated from Tilt Rotor Engineering 
Database System) 

The B 1 ackhawk helicopter, built by Sikorsky Helicopter of 
Stratford, CN 

Class of virtual-memory mainframe computers, product of 
Digital Equipment Corp. (DEC) 

Computer operating system used on the VAX computers 

Volume serial number (identification for magnetic tapes) 

Wt i te -One e - Read -Many attribute of laser-optical disk storage 

Experimental tilt-rotor aircraft built by Bell Helicopter 
Textron, Inc. of Ft. Worth, TX 
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appendix a 


trends 


Development Tasks Listed in Chronological Order 


November 1982 

Fatigue analysis at BHT 

December 1982 

Design initiated 
Data entry 

Use of TABLES software 

January 1983 

Minmax reformatting 

Bard-copy plots or the CDC 7600 computer 

Database summary 

Flight descriptions 

Search on numerical data 

Display of itemcode information 

Quas i-operat iott.i ACCESS (TRENDS) 

Study ot DATAMAP 

February 1983 

Operational ACCESS (TRENDS) software 
User help on Line 

Instrumentation groups in I.TEMDEFS 
Derived parameters (initial set) 

Reading 702 descriptive data 
TABLES^ 2 nd- level tables, absolute value, 
other terminals accommodated 

March 1 q B3 ckarch 

Store/ recall condition masks in SEARCH 

Show user’s DCS and MSK files 
Narrative categories in FLIGHTS 
CHARSORT for listing counter keywords 
“Xp time added to counter information 
VIEW reproduces listings from stored da 
Time-history storage, harmonic analysis 

^l^ntry of and access to -f-s H«C values 
CNTR as MINMAX ebscissa or SEARCH vanab - 

Selective dat a-copy ing , batch reformatting 
Datalrasing of o, re-line flight descriptions for 702 
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May 1083 

Plot set-up files saved/ recalled 
LOGSCAN implemented 

CTRL-C interrupts treated internally 

Bending moments displayed vs. blade station 

D^J' Unn,aX 3nd Lime - hist ory tapes processed 
RESCALE option for plots 

Determining column selects points to plot 
June 1983 

Time -history plotting 
Minmax-per-rev plotting 
Specific counters excludable from plots 
Plot-data tabulated to a file (PRINT) 

Itemcode descriptions searchable in ITEMDEFS 
Strings of numbers may be input tor data region 
Database summaries from database, not canned files 

July 1983 

Plotting: 5 p lots /page 

dual, independent plot y-scales 
single label for multiple same absrissae 
determining column for single-curve plots 
choice of curve symbols 

Checks on user-response validity (user-friendliness) 
Reformatting Tektronix data back into VAX for database 

August 1983 

Derived parameters include counter duration 
computed rpm, gross weight 
Filling database with narrative and data 
Wei berg s gross-weight-by-counter entered into database 
onversion of hard-copy plots from 7600 to Cray 

November 1983 

Initial Interface of DATAMAP with XV-15 database 
Summary- file generation ( FLTCTRMAP . KEY) 

December 1983 

Eady work on database-to-OTF for DATAMAP 
Ground-run numbers accepted as well as flights 

January 1984 

BUT standard- label to DTF reformatting 

DCNPRs P f | le " CI ? ation and Pressing integrated 
LCMPRS selects items to store atid decimates 

Prompting program for flight-log entry 
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February 1984 

Rotor-blipper extracted from control word, stored 
DCMPRS reads directly from tape, bypassing MTREAD 
Work toward command files for DCMPRS, BELMNMX 
Database s tatus -monitoring efforts 
Backup procedure -5 for database established 

March 1984 

Filtering of Hm?-hist or i es in DCMPRS 
Truncated time -histories in DCMPRS 

April 1984 

BELBAT for filtering, decimation, selectivity 
in processing 702 time-history tapes 
Filtering algorithms and convolution 
implemented and tested 

Separation into separate databases (disks, directories) 
and separation of software from data 

May 1984 

Subdirectories by data type (e.g. [DB703.MMR]) 

MMR plott i ng 

Manual entry of list of counters to usable DCS. 

De let, ion, replacement, edition, addition of flights 
in BASKER 

Hangar runs accepted as well as ground and flight 
Experimental (ACCESSX) software used in development 

June 1984 

Acceptance of group names (e.g. AER) in DTF creation 
program for DATAMAP 

Gross condition checks made on MMC database 
Da t aba se -management tools imp roved 

Numeric listing in ITEMDEFS as well as alphabetical 
ADDCOM tool for data-entry by NASA personnel 
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July 1984 

Comparisons of MMC from DCMPRS with those from FOX 
COPYFLTS minimizes file interference with users 
Maintenance program integrated into DATAMAP 
PRINT with options in TIMEHIST 

FILLMAT3 off-line database-access routine supplied 
Cross-checks for MMR, MMC vs. time-histories made 

August 1984 

New plotting dialogue in TIMEHIST 
Creation of SPG, RAW directories 

New f light-counter-key files created for summaries 
Automatic updating of summary files in DCMPRS 
Special keys devised for Long time-history records 
to handle the record-size limitation 

September 1984 

Math operations enabled in TTMFHIST 
Either-or and neither-nor enabled in WORDSCAN 
Interpolation to constant sample rate in DTF allows 
cross-plot and frequency response in DATAMAP 
Time-his tury group availability shown in WORDSCAN 

October 1984 

Min/Max plotting dialogue updated to match TIMEHIST ’ s 
December 1984 

Reve r se- chrono log ica 1 listing in LOGSCAN 
Show HQ,AER, etc. in WORDSCAN 

Interrupt WORDSCAN to show items stored for each group 
Utility routine, WHATDATA, scans any TRENDS item-file 

January 1985 

Utility software for database review 
Database management procedure automation 
Filtering of time-histories before storing in DCMPRS 
New ACCESS (TRENDS) menu 

TABLES and DATAMAP available via ACCESS (TRENDS) 

HELP capability added 
TERMINAL capability added 

FLIGHTS gives one-liners as well as full descriptions 
F1NDTHC reads and produces derived counter-sets 
DCS and F+number accepted at data-region prompts 
Multiple counters recognized for TIMEHIST data region 
MMR data plotted in TIMEHIST 

Polynomials calculated and plotted in TIMEHIST 

Time-to-next-inspection included in 703 one-line flight descriptions 
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February 1 Q R5 

New dialogue for MINMAX, including formulas, 


like TIMEHIST 


Functions (formulas) in SEARCH 

PLe-defined FUNCTIONS feature, evaluation 

Use of derived pseudo-items in MINMAX functions 

Mat h- 1 ibra ry routines (e.g. SIN) in functions 

KEYS, VIEW, WORDSCAN updated to use DCS, :+cntr, etc. 


March 1985 

Change aircraft -of -interest at any data-regiun prompt 
SEARCH efficiency improved with file re-use 
Climb- rate derived and stored for all P342 t ime-his tories 
Harmonics studied, computed, stored, accessed 


Apr i 1 1985 

702 harmonics tapes processed/analyzed 
Setup files developed for re-processing old PCM tapes 
requested by PH'J 
Derived items in DCMPRS 
Hardcopy print in DATAMAP 

K notation (for 1000s) for plot scales implemented 
Harmonic MMC type used in expressions 

HARMONIC menu- it eri for plotting harmonics vs. MMC expressions 

OSC and MAX statistics made usable in formulas 

Comparison of MMC measures from various processing sources 

May 1985 

Systematic procedure developed for processing requests 
Plotting of amplitude spectra in TRENDS 
REVDATA menu-item for loads display 

F1NDTHC uses THF1LES.CAT to display summary of available 
counters for time-history groups 
Printing of ampli 'tides /phases in HARMONIC 
M-scaling (for l,)00,000s) implemented tor plots 

June 1985 

Hard copy pints available as option 

"Groups" specified by name (previously by number) 

July 1985 

Hew database / d isk configuration (FHT2 for 702, FHT3 for 703) 
QWIKPLOT completed 

Automation of production of THFILES.CAT, harmonics, slopes 
Accessing of some RSRA data 

August 1985 
RSRA TRENDS 
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Seprember 1985 

Gross weights rev i ewed/ improved / user! in deriving parameters 
SEARCH and M INMAX recognize . SMO, . CMN t . CMX, . FSC measures 
Isabel t decimal places, units specifiable in SEARCH 
DATAMAP cross-hair feature activated 
Stanford seminar preparation and presentation 

Oc tube r 1985 

multi PI, T added to menu 

GTRS1M integrated with TRENDS 

ITEliDEFS expanded to include pseudo- items 

November and December 1985, January 1986 
INTERVAL in TIMEHIST 

New-versjon *.L1S files with automatic purging 
I1ELP/ALL for printable help 

REPORTX developed for scanning/plotting ACSYNT 
(aircraft synthesis program) data, including 
contour and families of plots 

February 1986 

FILES added, with keyed-access , reserved-name files 
replacing muLtiple user-fiJes 
Temperature-scan 703 data available for MINMAX & SEARCH 
Elimination of the DTF step for DATAMAP from TRENDS 
RSRA time-history data available / p lottable 
Generalization of software for multiple databases 
Interface between TRENDS databases and Tischler’s software 

March 1986 

CONVERT (VMS) used to compress databases 

Integration , different iat ion, convolution f i Itering enabled 

PRINT in TIMEHIST generalized to produce ASCII files 

SAVE (now STORE) for saving/ reca 1 1 ing derived time-histories 

Table lookup entry and use enabled in formulas 

Modularizing of TIMEHIST for better configuration management 

New RSRA minmax format treated 

User’s Reference Manual delivered 

A nr i 1 1986 

Scanned temperature data stored like other MMC data, 
eliminating the need for a special TEMP file 
FLIGHTS. 1ND (keyed-access) replaces six direct-access files 
and extra processing steps 
POLY coefficients displayed in plot legends 

Command file for routing hardcopy plots to plotting devices 
FINDTHC (*) lists all stored items of specified type 
Modularization of subroutine LABELS 
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May 1986 

TIME accepted in formulas in TTMF.HIST 
Blanks and E-notation enabled in formulas 
ITEMDEFS allows backing up to earlier prompts 
RESCALE at data-region prompt in M INMAX and TJMEHIST 
Preparation of off-line module for directly accessing 
TRENDS time-hisory data by an external program 
Radar tracking position and velocity data processed from 
RTM tapes for 7)3 and accessible in T1MEH1ST 

June 2986 

CALIBS accesses based calibration data for 703 
BASKER modified tor new FLIGHTS. IND format and to accept 
sequential- formatted ASCII as input 
Support of laser-optical disk demonstration 
Search of full text in FLIGHTS, storage and use of DCS 
Simulation of frequency sweeps for T1MEHIST and SPECTRA 
NOTCH filter implemented in T1MEH1ST 


July 1986 

FILES accesses other 
Simulation (GTRS1M) 
with other TRENDS 
Key numbers assigned 


users’ files with DIR, TYFE , COPY 
plotting brought into correspondence 
(formulas, POLY, scaling, PRINT) 
to GTRS1M run results for databasing 


August- 1986 

Modularization ol DISPLT, preparation for TEMPLATE 
Processing of sample AEFA compressor data 


September 1986 

ITEMDEFS groups expanded to include temperatures, radar 
s ides tick cont roller 

Adaptation of DISPLT to TEMPLATE at AEFA (beginning) 
Updating of RSRA TRENDS 

October 1986 

NORMALIZE option, work with TEMPLATE and AEFA 


November 1986 

RAW data moved t a a different disk from TTM for 703 
(first segmentation of a TRENDS database) 
Accommodation of AEFA formats, procedures, computers 

December 1986 

Procedures and User’s Manuals delivered 
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January 1987 

Utility software for correcting bad data in support files 
Radar data from RTM tapes compared with same from EDF 
EDIT capability developed for MiNMAX and TiMEHIST 

February 3987 

SAVE/RECALL of plot setups with EDIT 
On-site flight-test support for UH-60 at AEFA 
Rev-data processing installed for UH-60 
Software for comparing TRENDS stats with AEFA’s 
BTT10 (Boolean) added to library functions 
Database management (filling) tasks performed by NASA 
(first database management by other than AMA) 

UH-60 data accessible at ARC with TRENDS (as well as AEFA) 

March 3.987 

GTRSIM updated to latest standalone 

GTRS3M/TRENDS user documentation written as appendix to 
TRENDS User’s Manual 

Software analysis toolset applied to GTRSIM 
DATAMAP accepts UH-60 data 

April 1987 

GTRSIM interface modified 

Trip to Boe ing- Ve rt o L to demonstrate TRENDS 
Database management procedures and programs developed for 
handling dual AEFA/ ARC software and data for UH-60 

May .198 7 

Reading and storing of weather variables from Crow’s RTM 
tapes of radar and XV-15 data 
Cross-hair point-saving and storing to a file 
TITLE override of plot headers enabled 
GTRSIM : maneuver s imulat ion interfaced /checked 

better entry format for control positions 
printing and plotting of aerodynamic tables 
rime-jump accommodation work on UH-60 data 
TSillFT capability for shifting time-histories relatively 

June 1987 

Move TRENDS database to new NEP computer 
New calculations for gross weight 

GTRSIM’s aero tables labeled, pLotted, hardcopies delivered 
DATAMAP modified to use UH-60 blipper, enabling harmonic 
analyses and display vs. rotor azimuth 
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July 1987 

Accommodate npw de r ived-paramet er routing at AEFA 
Compute and store loads data for UH-60 
PERFPLOT developer 

Database-managemet t menu developed for UH-60 

HARMONICS activated for UH-60 

LOG SCAN t DERIVED enabled for UH-60 TRENDS 

August 1987 

Efforts towards generic TRENDS 

Crow’s landing weether data added to 703 database 
F I LLER-NEP (UH-60] modified to store harmonic data 
New time-bistory format designed and tested for counter- 
based files rather than item-based files 
Cross-hairs pickling in M1NMAX as well as in TTMEHIST 
Expression ditto t it or //X) to replicate complicated entries 
Scale ditto (") to force same scale for two y-curves 
INFOFILE specification prompt for TRENDS’ DATAMAP 
GTRS1M operational on new NEP 
Contour plots enabled off-line for GTRSIM 

September 1987 

TRENDS demo at BH r> 

Laser juke-box tests carried out at Percept ics 
USAGE developed for logging /d i splay ing TRENDS usage 
Menu for GTRSIM rather than list of two-character keys 
Pickling of control histories to be accepted by GTRSIM 

October 1987 

Consolidated TRENDS software on NEP1 disk 
Gross -we ight- by -counter investigation 
Spike corrections 

Comparison ulilit.es developed for UH-60 
TRENDS / TRENDX experimental version and procedures used 
Saving / recai 1 of an editable ASCII mask in SEARCH for XV13 
MULT1PLT in UH60 "RENDS menu 

GTRSIM: COMPARE to superimpose time histories 
PERFPLOT 

Inputs from flight data 

Correspondence list, of flight /sim mnemonics 
OUTSUB modularizes output statements in GTRSIM 
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November 1987 

Monitoring and summary of spiky or band-edging data 
Increase SPC time-history samples stored to 1025 
FILLER! VE modified for better gross reasonableness checks 
on numbers used in derivations 
FINDTHC : HAP added, question mark enabled for all items 
SELECT option added to WORDSCAN 

BENDING react ived off line for ATB and pre-ATB data 
TRMP option in GTRSIM (series of trims from flight DCS) 

Minmax comparison (printed) for GTRSIM flight/sim 
Data basing of minmax and time -history GTRSIM results 

December 1987 

Spike-removal efforts, de-spiked raw-data s torage / acces s 

De-spike routine developed 

AND and NOT. AND enabled in WORDSCAN 

TRENDS ’ GTRSIM matches resuLts of standalone version 
Graphical comparison of trim solutions for GTRSIM flt/sim 
Automatic, ovet ridable collection of flight data fur input 
to GTRSIM 

January 1988 

HARP wind-tunnel database added 

Comparison of short / long/ old/ new UH-60 minmax stats enabled 
Software analysis tools extended / updated and applied to 
TRENDS, GTRSIM and DATAMAP 
Database management menu for XV- 15 begun 

Database location for TRENDS conies from a file at run time 
rather than being hard-coded 

February 1988 

Wo t k toward automatic production of database status report 
T1MEHIST help menus and help text-files developed 
Utility developed to compute minmax stats from time-histories 
SUBINFO summary added to software analysis toolset 

March I ^88 

BV-360 wind-tunnel database added 

SEQN (sequential abscissa) enabled for MINMAX plots 
List- file logging and printing option at exit from TRENDS 
Modularization of production of list files in TRENDS 
New time-history format and special TRENDS to read it 
Detailed HELP menus for MINMAX, like TIMEHlST’s 
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Apr i l 1988 

Revision of 703 instrumentation groups 

Specification of source ami destination for UH-60 FILLER 
to alleviate storage problems 
Derived rotor parameters at mainframe rate for UH-60 
NUKER tool for UH-60 database managers to excise counters 

May 1988 _ . 

MOVER, FLAGGER tools developed for UH-60 database management 

PROJECT menu- item and information in database 
Testing of a laser optical disk with TRENDS 

June 1988 

EOF format converted to TRENDS format 

User’s Reference Manual (slanted to UH-60) delivered 
Presentation and participation at UH-60 Workshop 

July 1988 

HP2623 terminal-use enabled 
CPRINT (custom print) added 

XV- 15 project information accessed by PROJECT 
Main-rotor azimuth available as abscissa in TIMEHIST 
TRENDS access on a PC-AT (via modem) enabled 

August 1 Q 88 

New time-history format devised, tested 
and accessing nodules written 

September 1988 

Time-skew invest i gat ions / solut ions for 703 data 
Wild-card (*) re? ponses accepted for most data regions 
Generic KEYS with custom KEY ITEMS for XV- 15 
Condition mask f: le extended by tail number 

October 1988 

XV-15 item groups expanded to include new blade parameters (ATB) 
Accommodation of Cobra data 

BASECOM distributes database parameters, relieves hard-coding 
Demonstration of TRENDS /GTRS1H interface to NASA personnel 

Novembe r 1988 

Chinook and Apac.ie databases on FSD VAX 
December 1988 

Test version of ini tied TRENDS is operational 

User- gene rated files (e.g., FUNCTIONS) uniquely identified by database 
Prototype screen -managed menu developed 

January 1989 

Formatting of MDHC test tape to TRENDS format 

Training and instruction tor wind-tunnel software developer 

Database filling for Cobra data 
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Release of unified TRENDS 

Release of TRENDX with a screen- managed menu 

Development of a UH-60 database in counter-file format t access by TRENDS 
Development of a utility for page-numbering the TRENDS Report and 
concurrently updating a table of contents with the page numbers 

February and March 1989 

Delivery and installation of TRENDS at MDflC and the 40 x 80 wind tunnel 
Training/presentation of TRENDS at MDHC and the wind tunnel 
Moving of database management software from DBMGR data disk 
V2Z database installed (project data only) 

XV- 15 engine model data reformatted and pLinted 
BO- 1 05 database installed on FSD VAX 

Unification and improvement of the database management software 
Identification (date, time, name) included in user-generated files 
Project information enabled for all databases 

TRENDS generalized to access either old or new time-history formats 
Apr! I 1989 

Correction of switched (and correspondingly miscalibra ted ) data items 
in the UH-60 database 

Tagging of user-generated files with database extension 
Rotur-bl ipper signal synthesized for UH-60 flight 25 

Unification of 1TEM1NF0 treatment, improvement of wild-card in 1TEMDEFS 
Improvement of wild-card selection of data items in VIEW 

COMPARE improved and enabled for time-history comparisons between databases 
Plot titles and database symbols moved to the descriptor file 
Apache database on NEP written in new counterfile format on laser disk 
Extension of counterfile format to treat floating-point e.u. data 
Improvement of the GTRS1M iteiface, including s/w configuration control 

May 1989 

TRENDS installed on KRY VAX, along with the HARP database 
llemcode , as well as mnemonic , recognized in FIND 
Scanning and display of contour and family plots for CAMRAD 

June 1989 

Upgrading of TRENDS on MAR for quick- look ing at XV-15 data 
FREQN installed to enable "pec- rev" as abscissa in spectral plots 
Improvement of the software analysis toolset, FATS 
Initial steps for accessing Phase II Blackhawk data on F0X4 

Inly 1989 

Elforts toward processing new ('bad) XV-15 ground-test data on MAR 
Development and test of database filling and management software on F0X4 
TRENDS installed on F0X4 (required linking to accommodate new DISSPLA) 

Paper prepared and presented at Measurement & Instrumentation Workshop 
Work toward unification of the counter-description file throughout TRENDS 
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APPENDIX B 


SYNTAX FOR FORMULAS IN TRENDS 

TRENDS provides the user with a capability for combining the 
stored numeric il data according to his own formulas for the 
purpose of searching or plotting. These formulas may be entered 
at prompt-time or stored as named "functions" and recalled by 
name (see menu-item FUNCTION). They may be applied to either 
Min /Max (scalar) data or to time-histories. The general form 
of the mathematical expressions understood by TRENDS is: 


operand {operation operand} {operation ... operand} 


where the operations are any of +. -. *, /. ~ C is exponentiation). 

The operands are either: 

* itemcodes or derived itemcodes (with extensions, for minmax) , 

* literal numbers (E-notation accepted) , 

* names cf previously defined formulas (functions), 

* librar> functions with math-expression arguments, 

■>v previot sly defined univariate table name with 
math -express ion argument 

* "TIME” (for time-history plotting only) 

Parentheses may be used in the mathematical expressions to 
clarify the computational order. The default order of 
computation is left- to- right as encountered (reverse Polish 
notation). For example, 

Ml A 3 l M10 7 / 2 is equivalent to (M143+M10 1 ) / 2 

rather than to Ml 43+ ( M 1 0 7 / 2 ) as it would he in FORTRAN. 

All literal numbers are used as REAL*4 floating-point, 
whether or no; the decimal point is specified. 

It is important to note that the first field MUST be 
an OPERAND an i NOT an operation. Therefore, 

_M143 I s invalid, while 

- 1 *M1 4 3 )r 0-M143 are valid expressions. 
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Library functions 


The available library functions are REAL*4 functions of a single REAL *4 
argument, X, which may itself be a mathematical expression. 


SIN(X) 
COS (X) 
TAN (X ) 
ASIN(X) 
ACOS(X) 
ATAN(X) 
SQRT(X) 
EXP ( X ) 
LOG ( X ) 
LOGE(X) 
ABS(X) 
DERI V ( X ) 
INTEG(X) 
BIT10 (X) 


sine of angle X in degrees 

cosine of angle X in degrees 

tangent of angle X in degrees 

arcsine of X, returned in degrees (-90,90) 

arccosine of X, returned in degrees (0,180) 

arctangent of X, returned in degrees (-90,90) 

square root of (absolute value of) X 

exponential of X 

logarithm (base .10) of (absolute value of) X 
natural logarithm of (absolute value of) X 
absolute value of X 

first time derivative of X (time-history only) 
integral of X (time-history only). 

Boolean AND with the UH60 tail- rotor bit 


Univariate Table Look-up 


Univariate table look-up is also available in TRENDS. The table must be 
entered as a number of x,y pairs in your user-defined functions file, 

FUNCT IONS . A / C . If the table is called VGAIN, for example, VGAIN(X) may be 

used in any mathematical expression as an operand, where the argument X 
may also be an expression. Linear interpolation is used between table- 
points when X lies within the table’s independent- variable bounds. When 
X lies outside the bounds, the end-point y-value is returned. 

Valid Examples 


(Entries Jn user’s FUNCTIONS . 703 ) 

AVGT0RK = (M143 4 M107) / 2 1 named formula 

DATA VGAIN (0,23, 45,62.5, 100,83.7, 200,0, 300,-5) ! look-up table 


(In-line responses to plotting "Y-CURVE" prompt) 


SHAFT T0RQUE=M14 3 

STORE RS STORK = HI 43^2 4 (M107*2) A .5 
TRIG FN = ATAN ( SIN ( D1 86 ) / COS (D186) )-D161 
PSEUDOS = RSHP ^ SQRT(SIGP"3) 

TABLE VAL = 1.5 * VGAIN ( . 6 7 *P002 ) 
FN_OF_STORED_VAL = LOG ( RSSTORK) 
SCIENTNOTATION&TIME = M143*l . E-5*TIME 
AVG_VIB_TORK (FT-LB) = M143.0SC/12 
CL LMB_RATE ( FT /MIN ) = DERIV(P342) * 60 
AVERAGE TORQUE = AVGTORK/12 


l t e me ode 
formula 

library functions 
pseudo- items 
table 1 ook-up 
stored formula 
E-notation , TIME 
non-default measure 
calculus operations 
use of named formula 


In-line responses for MINMAX also apply 


to SEARCH responses . 
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appendix c 


PERFORMANCE GROUPS, XV-15 AND UH-60 


XV- 1 5 T1LTROTOR TIME-HISTORY GROUPS 


ITEM CODE GROUFS 

FILE TYPE 

AEROELASTTC 

*.TTM 

ARO: AEROELAST IC 

* . RAW 

BLADE 

* . RAW 

CONVERSION 

* . RAW 

HANDLING QUAL] TIES 

* . T IM 

HARMONICS 

* . SFC 

MANEUVERS 

*.TTM 

RADAR 

*.TIM 

RAW WING AEROELASTIC 

* . RAW 

SPECTRALS 

*.SPC 

TRANSFER FUNCTION 

* . RAW 


TIME HISTORY FILE DESCRIPTION 


FILTERED, FULL CNTR , 26 I.C.s 
UNFILTERF.P, FULL CNTR, 20 I.C.s 

UMF1LTERED , FULL CNTR, 50 I.C.s 

UNFILTERED, FULL CNTR, 23 I.C.s 

FILTERED, FULL CNTR, 108 I.C.S 
UNFILTF.RED , 1025 FTS/CNTR, ABFMS 

FILTERED, FULL CNTR, 88 I.C.s 
FILTERED, FULL CNTR, 19 I.C.s 
UNF1L.TERED , FULL CNTR, 9 I.C.s 
UNFILTERED, 1025 PTS/CNTR, ABFMS 
UNFILTERED, FULL CNTR, 13 I.C.s 
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XV- 15 HANDLING QUALITIES (PERFORMANCE) ITEM CODES 


1 

A005 

C.G. VERT VTP.R 

0 ’ s 

FILTER 
. 5 

S RATE 
5.0 

IN RATE 
125 . 5 

2 

AO 19 

PILOT SEAT VERT VIBR 

G’S 

. 5 

5.0 

2 51 

3 

A020 

COPILOT SEAT VERT VIBR 

G’S 

.5 

5.0 

251 

4 

A3 00 

C.G. LAT VIBR 

G’S 

. 5 

5.0 

125.5 

5 

A301 

C.G. F/A VIBR 

G’S 

.5 

5.0 

125.5 

6 

A3 02 

PILOT SEAT LAT VIBR 

G’S 

.5 

5.0 

251 

7 

A3 04 

COPILOT SEAT LAT VIBR 

G’S 

.5 

5.0 

251 

8 

A352 

C.G. VERT VIBR (SERVO) 

G’S 

3 . 0 

15.7 

31.4 

9 

A380 

PILOT SEAT F/A VIBR 

G’S 

.5 

5.0 

251 

10 

DOO 7 

ANGLE OF SIDESLIP 

DEG 

3 . 0 

15. 7 

31 . 4 

1 l 

D008 

ANGLE OF ATTACK 

DEG 

3.0 

15.7 

31.4 

12 

DOO 9 

ROLL ATTITUDE - CABIN 

DEG 

3.0 

15.7 

125 . 5 

13 

D010 

PITCH ATTITUDE - CABIN 

DEG 

3.0 

15.7 

125.5 

14 

DOH 

YAW ATTITUDE - CABIN 

DEG 

3 . 0 

15.7 

125.5 

i r> 

DO 21 

F/A STICK POSITION 

l 

3 . 0 

15 . 7 

125.5 

16 

D022 

LAT STICK POSITION 

X 

3.0 

15. 7 

125 . 5 

17 

D023 

POWER LEVER POSITION 

X 

3.0 

15.7 

31 . 4 

18 

D024 

PEDAL POSITION 

X 

3.0 

15. 7 

125.5 

19 

DO 2 5 

FFS F/A CYCLIC STICK POSITION 

Z 

FILTER 

3.0 

S RATE 
15.7 

IN RATE 
31 . 4 

20 

DO 2 6 

FFS LAT STICK POSITION 

Z 

3 . 0 

15. 7 

31 . 4 

21 

D02 7 

FFS RUDDER PEDAL POSITION 

X 

3.0 

15.7 

31 . 4 

22 

D1 56 

RT PYLON HUB SPRING F/A POS 

DEG 

3.0 

15.7 

31.4 

23 

D 1.57 

RT PYLON HUB SPRING LAT POS 

DEG 

3.0 

] 5 . 7 

31.4 

24 

D1 5 8 

RT PYLON COLL. ACTUATOR POS 

DEG 

3 . 0 

15.7 

31.4 

25 

D159 

RT PYLON S/PLATE F/A POSITION 

DEG 

3 . 0 

15.7 

125 . 5 

26 

D 160 

RT PYLON S/PLATE LAT POSITION 

DEG 

3 . 0 

15.7 

125.5 

27 

D 161 

RT PYLON CONVERSION POSITION 

DEG 

1.0 

5.2 

31.4 

28 

DL81 

LT PYLON HUB SPRING F/A POS 

DEG 

3.0 

15.7 

31.4 

29 

D182 

LT PYLON HUB SPRING LAT POS 

DEG 

3 . 0 

15.7 

31.4 

30 

D183 

LT PYLON COLL . ACTUATOR POS 

DEG 

3.0 

15.7 

31 . 4 

31 

D1 84 

LT PYLON S/PLATE F/A POSITION 

DEG 

3.0 

15.7 

125.5 

32 

D 1 8 5 

LT PYLON S/PLATE LAT POSITION 

DEG 

3.0 

15.7 

125.5 

33 

Di 8 6 

LT PYLON CONVERSION POSITION 

DEG 

1.0 

5.2 

31 . 4 

34 

D28 1 

ELEVATOR POSITION 

DEG 

3 . 0 

15.7 

31.4 

3 5 

D 2 8 4 

RUDDER POSITION 

DEG 

3 . 0 

15.7 

31 . 4 

36 

D305 

RT MAIN LDG GEAR OLEO EXT POS 

INCHES 

1.0 

5.0 

125 . 5 

37 

D306 

F/A SCAS ACTUATOR POSITION 

INCHES 

FILTER 

6.0 

S RATE 
31.4 

IN RATE 
125.5 

38 

D307 

LATERAL SCAS ACTUATOR POSITION 

INCHES 

6.0 

31.4 

125.5 

39 

D308 

DIRECTIONAL SCAS ACTUATOR POS 

INCHES 

6.0 

31.4 

125.5 

4 0 

D 3 0 9 

PILOT FLAP LEVER POSITION 

DEG 

3.0 

15.7 

31.4 

41 

D3 ! 4 

LT MAIN LUG GEAR ACT. POS 

INCHES 

1 . 0 

5.2 

31.4 

42 

D3 l 5 

LT MAIN LDG GEAR OLEO EXT POS 

INCHES 

1.0 

5.2 

31.4 

43 

D317 

RT MAIN LDG GEAR ACT. POS 

INCHES 

1.0 

5.0 

125.5 
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44 

D318 

DTFF. CYCLIC WASHOUT ACT. POS 

45 

D327 

ALTITUDE - RADAR ALTIMETER 

46 

D 3 4 9 

NOSE L )G GEAR OLEO EXT POS 

47 

D509 

RT THR ITTLE POSITION 

48 

D5.10 

LT THRITTLE POSITION 

49 

D617 

FLAP POSITION 

50 

D645 

RT WIND AILERON POSITION 

51 

D646 

LT WIND AILERON POSITION 

52 

D7 4 6 

RT COLLECTIVE LVDT 

53 

D747 

RT Fl.APERON LVDT 

54 

D776 

S/S LONG STICK COMMAND 


55 

D777 

S/S PITCH ATTITUDE COMMAND 

56 

D779 

S/S LAT STICK COMMAND 

57 

D780 

S/S RCl.L ATTITUDE COMMAND 

58 

D792 

S/S PEDAL COMMAND 

59 

D 7 99 

LT COI LECTIVE LVDT 

60 

D800 

LT FL/PERON LVDT 

61 

E069 

RPM CMD 

62 

EO 70 

STEY-MA 

63 

E717 

PRIMARY GOV SERVO VALVE 

64 

E 7 1 8 

PR I MARY GOV RPM ERROR 

65 

E 7 19 

PRJMAF.Y GOV //I LVDT 

66 

E 7 20 

PRIMARY GOV ACT. VELOCITY 

67 

E72 1 

PR IMAP. Y GOV COMMAND RPM 

68 

E 7 22 

PRIMARY MONITOR COMMAND RPM 

69 

E72 3 

FR1MAP.Y MONITOR RPM ERROR 

70 

E7 24 

STANDBY GOVERNOR RPM ERROR 

71 

E748 

RT COLLECTIVE EXCITER SOLENOID 

72 

E 7 4 9 

RT FLjVPERON EXCITER SOLENOID 


73 

E750 

LT COLLECTIVE EXCITER SOLENOID 

74 

E 751 

LT FLAPERON EXCITER SOLENOID 

75 

F03 0 

FFS F/A CYCLIC STICK FORCE 

76 

F03 1 

FFS LATERAL STICK FORCE 


77 

F033 

FFS RJDDER PEDAL FORCE 


78 

FI 62 

RT F/A CYCLLC ACTUATOR 

FORCE 

79 

F16 3 

RT LAT STICK ACTUATOR FORCE 

80 

F1.64 

RT COLLECTIVE ACTUATOR 

FORCE 

81 

F 18 7 

LT F/A CYCLIC ACTUATOR 

FORCE 

82 

F I 88 

LT LAT STICK ACTUATOR FORCE 

83 

FI 89 

LT COLLECTIVE ACTUATOR 

FORCE 

84 

F330 

F/A CYCLIC STICK FORCE 


85 

F331 

LATERAL STICK FORCE 


86 

F333 

RT RUDDER PEDAL FORCE 


87 

F334 

LT RUDDER PEDAL FORCE 


88 

F 7 7 5 

S/S LONG FORCE 


89 

F778 

S/S LAT FORCE 


90 

Ml 0 7 

RT RC TOR MAST TORQUE 

12 


INCHES 

FEET 

INCHES 

DEG 

DEG 

DEG 

DEG 

DEG 

X 

% 

INCHES 


DEG 

INCHES 

DEG 

INCHES 

l 

X 

X 

? 

MAMPS 

£ 

X 

D/SEC 

l 

X 

X 

l 

VOLTS 

VOLTS 


VOLTS 

VOLTS 

LBS 

LBS 

LBS 

LBS 

LBS 

LBS 

LBS 

LBS 

LBS 

LBS 

LBS 

LBS 

LBS 

LBS 

LBS 

IN LB 


3.0 

1 .0 

1.0 

3.0 

3.0 

3.0 

3.0 

3.0 

10.0 

10.0 

3.0 

FILTER 

3.0 

3.0 

3.0 

3.0 

10.0 

10.0 

3.0 

3.0 

3 . 0 

10.0 

3 . 0 

3.0 

3.0 

3 . 0 

10.0 
in, o 
1 o . 0 

10.0 

FILTER 

10.0 

10 . 0 

3 . 0 

3.0 

3.0 

3.0 

3 . 0 

3 . 0 

3.0 

3.0 

3.0 

3.0 

3.0 

3.0 

3 . 0 

3.0 

3.0 

3.0 


15.7 

5.2 

5.0 

15.7 

15.7 

15 . 7 

15.7 

15.7 

31.4 

31.4 

15.7 

S RATE 

15 . 7 
15 . 7 

15.7 

15 . 7 

31.4 

31.4 

15.7 

15.7 

15.7 

31 . 4 
15 . 7 

15.7 

15.7 
15 . 7 

31.4 
31.4 
31 .4 

31 . 4 

S RATE 

3.1 . 4 

31.4 
15. 7 

15.7 

15.7 
15. 7 

15.7 

15.7 

15.7 

15.7 

15.7 

15.7 

15.7 

15 . 7 

15.7 

15.7 

15.7 

15.7 


31.4 
31.4 
125.5 
31.4 
31.4 
31. 4 
125.5 
125.5 
125.5 
125.5 
31.4 

IN RATE 
31.4 
31.4 
31.4 
125.5 
125.5 
125.5 


125.5 
125.5 
125.5 
125.5 
31 .4 
31 . 4 
125.5 
31.4 
31.4 
31.4 

IN RATE 
31 .4 
31 . 4 
31 . 4 
31.4 
31.4 
251 
251 
251 
251 
251 
251 
125.5 
125.5 
125.5 
125.5 
125.5 
125.5 
251 
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FILTER 

S RATE 

IN RATE 

91 

Ml 4 3 

LT ROTOR MAST TORQUE 12 

IN LB 

3.0 

15.7 

251 

92 

M791 

S/S TORQUE 

IN LB 

3 . 0 

15 . 7 

251 

93 

POO 2 

AIRSPEED - NOSE ROOM 

KNOTS 

1 . 0 

5.0 

125.5 

94 

P342 

APTITUDE - NOSE BOOM 

FEET 

1.0 

5.2 

31.4 

95 

Ri 06 

ROTOR RPM 

l 

3.0 

33 .4 

125 . 5 

96 

R328 

RT ENGINE FUEL FLOW RATE 

LB/HR 

1.0 

5.0 

125 . 5 

97 

R329 

LT ENGINE FUEL FLOW RATE 

LB/HR 

1.0 

5.0 

125.5 

98 

R338 

RT ENGINE N2 RPM 

2 

6.0 

31.4 

125.5 

99 

R339 

LT ENGINE N2 RPM 

I 

6.0 

31.4 

125.5 

100 

R503 

RT ENGINE N1 RPM 

l 

3.0 

15.7 

125.5 

10 L 

R5.L5 

LT ENGINE N.1 RPM 

l 

3 . 0 

15 . 7 

12 5.5 

102 

T322 

OAT (ROSEMONT) 

DEG C 

1.0 

5.2 

31.4 

103 

VO 12 

ROLL RATE - CABIN ( INCOMPLETE ) 

D/SEC 

3.0 

15.7 

125.5 

] 04 

V013 

PITCH RATE -CABIN (INCOMPLETE) 

D/SEC 

3.0 

15.7 

125.5 

105 

VO 1 4 

YAW RATE - CABIN (INCOMPLETE) 

D/SEC 

3.0 

15.7 

125.5 

3 06 

VO 1.5 

ROLL RATE - SCAS 

D/SEC 

3.0 

15 . 7 

125.5 

107 

V 0 1 6 

PITCH RATE - SCAS 

1)/ SEC 

3.0 

15. 7 

125.5 

108 

VO 1 7 

YAW RATE - SCAS 

D/SEC 

3.0 

15.7 

125.5 
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JH-60 BLACKHAWK INSTRUMENTATION GROUPS 


TC Test Conditions 
AP Aircraft Parameters 
RP Rotor Parameters 
VP Vibration Parameters 
EP Engine Parameters 
DP Derived Parameters 




UH-60 BLACKHAWK TEST-CONDITION ITEMS 




Seq 

1 1 em 

Desc r i p t ion 

Uti 1 1 s 

Ic: ode 

Freq 

Rate /Dec 

1 T 

ALTHA 

Angle of attack 

Degs 

DAAO 


32/1 

2 T 

AXCG 

Linear accel CG , longitudinal 

G 1 s 

DL00 

5. 

129/4 

3 T 

AYCG 

Linear accel CG, lateral 

G* s 

DL01 

5. 

129/4 

4 T 

AYCGSENS 

Sensitive lateral acceleration 

G* s 

AF90 

5. 

129/4 

5 T 

AZCG 

Linear accel CG , normal 

G's 

DL02 

5. 

129/4 

6 T 

BETA 

Angle of sideslip 

Degs 

DSSO 


32/1 

7 

HEADTN 

Aircraft Heading @25sps 

Degs 

DAI 2 


32/1 

8 T 

HEADING 

Aircraft Heading 

Degs 

DAO 2 

5. 

129/4 

9 T 

LSSX 

Raw Airspeed (LASSIE) Long 

Kts 

VXO 3 

1 . 

32/6 

10 T 

LSSY 

Raw Airspeed (LASSIE) Lateral 

Kts 

VY03 

1 . 

32/6 

11 T 

LSSZ 

Raw Airspeed (LASSIE) Vertical 

Ft /Min 

VZ 0 3 

1 . 

32/6 

12 T 

PA l GB 

Boom altitude 

inHg 

H001 

1 . 

32/6 

13 T 

PAICS 

Ship’s altitude 

inHg 

H002 

1 . 

32/6 

14 

PTTCHAT 

Pitch attitude 0 25 sps 

Degs 

DA 10 


32/6 

15 T 

PITCHATT 

Attitude, pitch angle 

Degs 

DA00 

5. 

129/4 

16 T 

PTCHACC 

Pitch acceleration 

Deg / s2 

DACO 

2. 

129/8 

17 T 

PTCHRATE 

Angular rate, pitch 

Deg / s 

DR00 

5. 

129/4 

1R T 

QC1CB 

Boom airspeed 

inHg 

VO 01 

1 . 

32/6 

19 T 

QC1CS 

Ship ’ s a irspeed 

inHg 

V002 

1 . 

32/6 

20 T 

RADALT 

Altitude (Radar Range) 

Feet 

H003 

1 . 

32/6 

21 

RECORD 

Record number 

J tidex 



32/6 

22 T 

ROI.LACC 

Roll acce l et at ion 

Deg / s 2 

DAG 1 

2. 

129/8 

23 

ROLLAT 

Roil attitude @ 25 sps 

Degs 

DA 11 


129/8 

24 T 

ROLLATT 

Attitude, roll angle 

Degs 

DA01 

5. 

129/4 

25 T 

ROLLRATE 

Angular rate, roll 

Deg/ s 

DR01 

5 . 

129/4 

26 T 

TTIC 

OAT Outside Air Temperature 

Deg C 

T 100 

1 . 

32/6 

27 T 

YAWACC 

Yaw acceleration 

Deg/ s2 

DAC2 

2 . 

] 29/8 

28 

YAWATT 

Alternate for heading 

Deg 

DA22 


129/8 

29 T 

YAWRATE 

Angular rate, yaw 

Deg/ s 

DRO 2 

5. 

129/4 
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APPENDIX D 


FILE STRUCTURE CONSIDERATIONS 

One must consider many factors when choosing a file structure for a 
database. Some of these factors are: 

1. How will the information from the database be used? 

2. How much data must lie archived? 

3. Vihat are the procedural limitations and constraints? 

The basic keys for databased numerical (e.g., Min /Max or time-history) 
records are (1) item name (itemcode, mnemonic, etc.) and (2) counter 
(test-point, identifier). That is, given the data item and test-point 
index, the data record should be identified for retrieval. Of course, 
We are assuming that the database is given and that item and counter 
are unique within that database. Such attributes as data type or 
repeated records will be ignored for now. There are many tile and 
record structures one could propose for numerical records. 

Option 1: All of the item/counter data might be in one file 

keyed either by a composite item/counter code or by 
primary (e.g., item) and secondary (e.g., counter) keys 

Option 2: All of the data in the base for one item might be in one 
file (one file per item) and be keyed by counter 

Option 3: All of 1 he data in the base for one counter might be in 
one file (one file per counter) and lie keyed by item 

Option 4: Each item/counter pair might be a separate file (name 
code specifies item and counter, no keying necessary) 

The following FORTRAN code shows how Option 2 is implemented in TRENDS. 

OPEN (UNTT=2, NAME-FILENAME, STATUS= ’ OLD ’ , 

1 ORGANIZATION^ ’ INDEXED’ , ACCESS= ’ KEYED ’ , 

2 <EY=( 1. : 4 : INTEGER) , READONLY, SHARED, 

3 !ECORDTYPE= ’ VARIABLE ’ , FORM= ’ UNFORMATTED ’ ) 

JCTR = 14502 1 Counter number 

READ ( 2 , KEY=JCTR , ERR=3 50 ) IC.TR, SCALE, BIAS, START, SAMPSEC, 

1 NPTS , ( 12DAT ( I ) , 1=1 , NPTS ) 

DO 201 1=1, NPTS 

200 EU( 1 ) = SCALE * FLOAT ( I2DAT ( I ) ) + BIAS 
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This example reads time-history data in integer counts into an 
array, I2DAT , then converts the data into an aitay, EU, in 
floating-point engineering units for plotting or math operations. 

Notice that the key is the counter number, an integer. For Option 3, 
the record key would he the itemcode, a character variable. 

The choice among the many opt ions is made by considering t he likely 
use of the data, the ease of programming the access, database 
management, requirements (e.g., deleting, copying the stored data), 
resultant file size, traceability through modularity, etc. 

Option 2 was originally selected for TRENDS for storing both Min/Max 
and time-history data. Reconsideration of the usage requirements and 
constraints of the system has led to a decision to change time-history 
file structures to Option 3 in the future. Option J was ruled out 
because it implies one gigantic file for each data type (or worse, 
for ALL data types, such as Min /Max-pe r-coun te i , filtered time- 
histories, etc.). This file would be too unwieldy for database 
management operations where special techniques are required to avoid 
locking up files while filling and where smaller files are better 
procedural ly for accommodating such problems as computer crashes. 

Option 2 implies a fairly fixed number of files (one for each item), 
each of which grows as new counters are added to the database. Option 3 
implies a lair Ly fixed number of records in each tile (file size 
depending on test-point duration and sampling rate), where the number 
of files grows as new counters are added to the database. Option 4 
would result in a ridiculous proliferation of files (the number being 
the product of the number of items and the number of counters for each 
data type) and in too much opening and closing of tiles during access. 
Time-frame format storage is not even considered, because it takes too 
much work and time to extract the information to be displayed or 
searched . 

The multiflight requirement is currently impacting the time-history 
data format as the system goes from 5 to 80 gigabytes via the use of a 
laser-disk jukebox. The original file format (Option 2) was multi- 
t Light-oriented by allowing each parameter to have a single file and 
by keying the records in it to the test -point numbers. New higher 
data sampling rates (for multiple flights) are forcing NASA to go to 
a multidisk storage system to handle the high volume of data, where the 
time-history data for one parameter might well span more than one disk 
if kept in the original format. Option 3, which has one file per test 
point (the file data for all parameters for that test point) is better 
for this situation because each disk could be made to hold an integral 
number of test points. This format may not be as efficient in execu- 
tion as t hat of Option 2, but. has logistical advantages because of the 
laser disk medium and the need to migrate data. 

A version of the Option 3 format has been adopted at Ames to serve 
as the standard database time-history format serving both DATAMAP 
and TRENDS. This format is called the DAT-TH format. 

The format requirements for Min/Max data are different from those 
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far t ime-hi st ory da.., Let «. consider the advantages an 1 d * van- 
usine Option 2 (one file ,iei item, keyed by cuuntei > for 
MiiHMBX opt rat inns . The two most frequent uses of Hrn/Hax data in 

i r m fr,ta (I i cjh I av one it em s vslues ins t 

tomiirpq oneninp only one file. lo display one . . 

another’s ::or a large number of counters squires opening and rea, mg 

on i v two files. If the files were counter-named and item-keyed 

(Ontion 3) a new file would have to he opened, read, and closed for 

each different counter in the specified data region. A disadvantage of 

Option 2 i? seen in block-prints (snapshots displaying multiple 1 . 

or expressions involving multiple items) of many items together for a 

few counters. Another difficulty comes in deleting or mrgra ting one 

tZn,ev or flight or segment from the database. Each 1 tern- file must 

then l.e specified, opened, treated, and closed separately. On the 

other hand! the Hem-tile for a completely dead or faulty sensor can 

simply be deleted and full database information for a single Hem 

be copied with VMS system commands. 
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appf.ndtx e 

HIERARCHY CHART FOR TRENDS 


The subroutines are : 


AMPSET 

AMPSIC 

ASKF1LE 

BANK 

BLDFUFMAT 

BI.OCKOUT 

CHANGE 

CHANOE_SETUP 

CHEKFUMC 

COMPHDR 

CONTI '.NTS 

CREATION 

CURVE FIT 

CVFILT 

CVGEN 

CYCLAVG 

DCS READ 

DCS SAVE 

DRWCRV 

ECR 

EDITPP 

EQUATIONF 

EVALUATE 

EXPOSE 

Fit, DAT 

FILTER 

FI NDTHC 

Fl.TLOG 

FMNMAX 

FMTRATE 

FRFII.L 

FRMAT 

FUNC 

GETERM 

GETF jTS 

GETMMC 

G1CSUB 

GRPL 1ST 

HANDLER 

HELPHDCPY 

IN DA FA 

1NFJI.ES 

INVERT 

ITEM IODE 

1 TEMDEFS 

LEGENDS 

LIBDI 

LOADSUH 

MENU 

MINMAX 

MPLOTS 

NICER 

NORMALIZE 

NOTCH F 

OPENFILE 

OPSHNS 

PARSER 

PLTHDR 

Pl.TLABLS 

PLTSET 

PREPLOT 

PREPLOTF 

QW1KPL0T 

RFFT 

FNUMB 

RN1IMBA 

ROTDF.G 

ROTPUL 

SCLARF.P 

SEARCH XV 

SECYAX 

SETACSN 

SETSCL 

SETt'Pl 

SETUP2 

SHOFLT 

SHOKEY 

SHOMNMX 

SHOV/DCS 

SHOVFILE 

SHOWFORM 

SIMS IGNAL 

SIMS PEC 

SMG MENU 

SPECTRAL 

STRINGS 

SUBMENU 

THFOPEN 

TH ITEMS 

TIIPRNT 

TRF.ND98 

UPDE TATS 

USERFILES 

WORDSCAN 

XAXJ S 

XKMSCL 

In the following hierarchy 

chart , " * 

and ^ 1 ine 

n" me mis ’’lower 

branches 

Level 

Level Level Level Level . 

0 

1 2 3 

4 

1 TREND98 


2 > 

CHANNEL * 


3 > 

ENABLE 


4 > 

> LIB$STOP 

* 

6 > 

LOGOUT 


7 > 

> DATE 

■k 

8 > 

> TIME 

* 

10 > 

SETAC5N 



AVECYC 

AZTMUTH 

BUZZER 

CAST 

CK DAT NAM 

COMPARE 

CRSHAR 

CUBFIT 

CVTUPC 

CYAVST 

DERIVED 

DISPLT 

ENABLE 

EQUATION 

EXPOSF.F 

FFT 

FLAGCHEK 

FI.T2CTR 

FOPEN 

FORPTC 

FUNKSHN 

GENUELP 

GF.TNPLOT 

GETNPLOTF 

HELP 

HELPER 

INFUNCS 

INREAD 

TTEMVU 

LABELS 

LOADSXV 

LOGOUT 

MSKFILE 

MULTIPLT 

ONEL1NER 

OPENCNTRF 

PERFPLOT 

PICTR 

PLTSETUP 

PLTSETUPF 

READUPC 

REDNOSE 

RNUMBR 

ROTCOR 

SCRO_MENU 

SEARCHUH 

SET BASE 

SETERM 

SHIFTY 

SHOCAL 

SHONARTV 

SHOSUM 

SHOWTH 

SHOWVAR 

SORT 1 A 

SORTX 

TEKVT 

TERMTYPE 

T IMEHIST 

TIMEOUT 

WHATF1LES 

WHATSAVE 

YAXIS 

YKMSCL 


means "not in the list of subroutines” 
lready expanded above, line n . ” 


(TRENDS Main Program) 
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] 1. > > READUPC 

12 > > INFUNCS 

13 > > > CVTTJPC 

14 > > > PARSER 

16 > > SETBASE 

17 > > > STRINGS 

20 > SET_TERM_HCPY * 

21 > ECR 

22 > INFUNCS nine 12 

23 > INFILES 


24 

> 

MENU 




(TRENDS Menu Prompter) 

25 

> 

> 

SCRO 

MENU 




26 

> 

> 

> 

READUPC 



28 

> 

> 

SMG_ 

MENU 




29 

> 

> 

> 

OPSHNS 



30 

> 

> 

> 

CVTUPC 



31 

> 

> 

> 

CHANGE SETUP 


32 

> 

> 

> 

> 

SUBMENU 


33 

> 

> 

> 

> 

SETACSN 

nine 10 

36 

> 

> 

GENHELP 




37 

> 

> 

> 

READUPC 



38 

> 

> 

> 

HELP 




39 

> 

> 

> 

HELPER 



40 

> 

> 

> 

> 

PEADUPC 


41 

> 

> 

> 

> 

LOGOUT 

nine 6 

42 

> 

> 

> 

> 

1TEMDEFS 


43 

> 

> 

> 

> 

> 

LOGOUT 

nine 6 

4 4 

> 

> 

> 

> 

> 

FOPEN 


45 

> 

> 

> 

> 

> 

READUPC 


46 

> 

> 

> 

> 

> 

CVTUPC 


47 

> 

> 

> 

> 

> 

FMTRATE 


48 

> 

> 

> 

> 

> 

HELP 


50 

> 

> 

> 

> 

SHOWFOFM 


51 

> 

> 

> 

> 

WHATSAVE 


52 

> 

> 

> 

> 

> 

READUPC 


54 

> 

> 

> 

> 

HELPHDCPY 


55 

> 

> 

> 

> 

HELP 



56 

> 

> 

> 

> 

SHOWTH 


5 7 

> 

> 

> 

> 

F1NDTHC 

(FIND Menu Item) 

58 

> 

> 

> 

> 

> 

LOGOUT 

"line 6 

59 

> 

> 

> 

> 

> 

READUPC 


60 

> 

> 

> 

> 

> 

CONTENTS 


6 i 

> 

> 

> 

> 

> 

> FOPEN 

63 

> 

> 

> 

> 

> 

THITEMS 


64 

> 

> 

> 

> 

> 

> READUPC 

65 

> 

> 

> 

> 

> 

> REDNOSE (Number entry parser) 

66 

> 

> 

> 

> 

> 

> > 

READUPC 

67 

> 

> 

> 

> 

> 

> > 

CHANGE 

68 

> 

> 

> 

> 

> 

> > 

> PARSER 

69 

> 

> 

> 

> 

> 

> > 

> SETACSN nine 10 

70 

> 

> 

> 

> 

> 

> > 

> GETERM 

71 

> 

> 

> 

> 

> 

> > 

> > READUPC 


E-2 


73 
7 4 
75 

77 

78 

79 

80 
82 

83 

84 

87 

88 
89 
93 
9 4 

95 

96 

97 

98 

99 

103 

104 

105 

106 

107 

108 
109 
1 10 
112 
113 

115 

116 
117 

119 

120 
122 
123 

125 

126 

127 

128 

129 

130 

133 

134 

135 

136 

137 

138 

139 

1 4 1 

142 


> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 


> 


> 

> 

> 

> 

> 

GETHCPY * 



> 

> 

> 

> 

> 

THPRNT 

> 


> 

> 

> 

> 

> 

> HELP 



> 

> 

> 

> 

> 

EDITPP 

> 

> 


> 

> 

> 

> 

> 

> WHATFT.LES 



> 

> 

> 

> 

> 

> READUFC 

> 

> 


> 

> 

> 

> 

> 

> PARSER 

> 


> 

> 

> 

> 

> 

REAT'UPC 

> 


> 

> 

> 

> 

> 

RNUMBR 

> 


> 

> 

> 

> 

> 

> RNUMB 

> 


> 

> 

> 

> 

DCSREAD 

s 


> 

> 

> 

> 

> 

ASKFILE 

> 

> 

> 

> 

> 

> 

> 

> READUPC 

> 

> 

> 

> 

> 

SORTTA 


> 

> 

> 

> 

> 

DCS SAVE 



> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 


> 

> 

> 


> 

> 

> 


> 

> 

> 


> 

> 

> 


> 

> 

> 

A 

A 

A 

> 

> 

> 

> > > 

> 

> 

> 

STRINGS 

> 

> 

> 

FOPEN 

> 

> 

> 

REDNOSE 

> 

> 

> 

THFOPEN 

> 

> 

> 

SHOWTH 

> 

> 

> 

SHOWDCS 

> 

> 

> 

FLT2CTR 

> 

> 

> 

> SORT I A 

> 

> 

> 

OPENCNTRF 

> 

> 

> 

> FOPEN 

> 

> 

> 

INREAD 

> 

> 

> 

SORT I A 

> 

> 

> 

DCSSAVE 

> 

> 

SHOWDCS 

> 

> 

SHOMNMX 

> 

LOGOUT 

"line 6 


READ!? PC 
ASKFILE 
CREATION 

DATE 
TIME 


line 65 


"line 88 


line 94 


> HELPHDCPY 

SETACSN "line 

GETERM "line 

GETHCPY * 

HELP 

LIBDO 

> L1BSS1GNAL 


10 

70 


S HO SIM 


(HELP Menu Item) 


(DATABASE Menu Item) 


> 

> 

> 

> 

> 

> 

SHOFLT 

> LOGOUT 


SHOWTH 

SHOMNMX 

SHONARTV 

REAUUPC 

LOGOUT 

0NEL1NER 


1 ine 


"line 


(FLIGHTS Menu Item) 
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14 3 

> 

> 

READUPC 



144 

> 

> 

DCSREAD 

"line 

87 

1 45 

> 

> 

FOPEN 



146 

> 

> 

PARSER 



147 

> 

> 

SHONARTV 



148 

> 

> 

SORT! 4 



149 

> 

> 

DCSSAVF 

* 


1 5 i 

> 

FLTLOG 



152 

> 

> 

LOGOUT 

"line 

6 

153 

> 

> 

READUPC 



155 

> 

SHOKEY 



156 

> 

> 

logout 

" 1 ine 

6 

157 

> 

> 

FOPEN 



158 

> 

> 

REDNOSE 

"line 

65 

159 

> 

> 

SHOWDCS 



.3 60 

> 

> 

FLT2CTR 

"line 

109 

161 

> 

> 

FLAGCHEK 



163 

> 

ITEMVU 



164 

> 

> 

LOGOUT 

"line 

6 

165 

> 

> 

FOPEN 



166 

> 

> 

REDNOSE 

"line 

65 

167 

> 

> 

SHOMNMX 



168 

> 

> 

SHOWDCS 



169 

> 

> 

FLT2CTR 

" I ine 

109 

170 

> 

> 

READUPC 



1/1 

> 

> 

HELP 



172 

> 

> 

DEFITEMSUH 



1 73 

> 

> 

FLAGCHEK 



175 

> 

BL0CK0HT 



1 76 

> 

> 

LOGOUT 

" 1 ine 

6 

17 7 

> 

> 

READUPC 



178 

> 

> 

BLDFORMAT 



179 

> 

> 

> READUPC 



181 

> 

> 

STRINGS 



182 

> 

> 

REDNOSE 

"line 

65 

183 

> 

> 

FLT2CTR 

"line 

109 

184 

> 

> 

EVALUATE 



185 

> 

> 

> EQUATION 


186 

> 

> 

> > FOPEN 


188 

> 

> 

> FUNC 



191 

> 

SEARCHXV 



192 

> 

> 

LOGOUT 

nine 

6 

193 

> 

> 

DATE 

'k 


194 

> 

> 

TIME 

* 


195 

> 

> 

FOPEN 



196 

> 

> 

READUPC 



197 

> 

> 

MSKF1LE 



1 98 

> 

> 

> READUPC 



200 

> 

> 

HELP 



201 

> 

> 

EQUATION 

"line 

185 

202 

> 

> 

RNUMBA 



203 

> 

> 

> RNUMB 




(LOGSCAN Menu Item) 
(KEYS Menu Item) 


(VIEW Menu Item) 


(CPRINT Menu Item) 


(SEARCH Menu Item, XV- 15) 
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205 

> 

> 

CREATION 

" ] i ne 

97 

206 

> 

> 

RF.DNOSE 

''line 

65 

207 

> 

> 

SHOWDCS 



208 

> 

> 

fHNC 



209 

> 

> 

FRMAT 



210 

> 

> 

JPDSTATS 



211 

> 

> 

SORT I 4 



212 

> 

> 

DCSSAVE 

"line 

94 

214 

> 

SEARCH HI 



215 

> 

> 

FOPEN 



216 

> 

> 

LOGOUT 

"line 

6 

217 

> 

> 

DATE 



2.18 

> 

> 

TIME 

•k 


219 

> 

> 

READUPC 



220 

> 

> 

MSKF1LE 

" line 

197 

221 

> 

> 

HELP 



222 

> 

> 

RNUMBA 

"line 

202 

223 

> 

> 

EQUATION 

* 1 ine 

185 

224 

> 

> 

CREATION 

"line 

97 

225 

> 

> 

REDNOSE 

"line 

65 

226 

> 

> 

SHOWDCS 



227 

> 

> 

FLAGCHEK 



220 

> 

> 

FUNG 



229 

> 

> 

FRMAT 
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687 

> 

> 

;■ TEKVT 


690 

> 

GRPL1S 

i rn 


691 

> 

> 

1’OPEM 


692 

> 

> 

LOGOUT "line 


693 

> 

> 

READUPC 


694 

> 

> 

(;icsub 


696 

> 

DERIVED 


697 

> 

> 

] 7 0PEN 


698 

> 

> 

LOGOUT "line 


699 

> 

> 

READUPC 


700 

> 

> 

AELP 


701 

> 

> 

dELPHDCPY 


703 

> 

DOMEPL * 


704 

> 

L1BU0 

"'line 129 



(GROUPS Menu Item) 


(DERIVED Menu Item) 
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appendix f 


DATABASE VECTORING 


Current 

TRENDS, 

stored 

vector 


NASA Procedure 
running under 
on one of five 
is constructed. 


s for Data Access: Commands are currently constructed in 
VMS to allow the user to access any database which can be 
different disk drives. In the following example, a path 
then used to retrieve file data off a magnetic disk farm. 


$ ASSIGN NEP1: (TRENDS JDBASE. RUN 
$ RUN NEP1 : [TRENDS JXVTRENDS 

Note: In the above assignment NEP1 

TRENDS 
DBASE. RUN 
FOR098 
XVTRENDS 


F0R098 


= disk name (NEPTUNE) 

= main TRENDS directory (DB Op. Sys) 

= database pointer file 

= logical unit 98 

= executable TRENDS program 


Note: When the user enters into TRENDS, he is requested to select his database, 
e.e. 748, 702, 702, etc. (various rotorcraft databases). His selett.io 

determines tie path (drive name and directory) to the database as follows 


1. $ Read unit 9E 


2. $ Construct F .lename 


! find the path to sections of databases 
1 Note: Different sections (files) of a 
I database can be on different disks for 
I the same rotorcraft. Contents of file 
I 98 are identified by key words, e.g. 

1 DRIVER, DOC, DATA, etc. 

1 Access data by cnncatenat i.ng path 
l from unit 98 with dataset tile names 


e.g 


FILENAME = ’ N'*!P3 : [DB703] ’ / / ’C70313258.225’ 
(fr:>m unit 098) (tile name) 


3. $ Open Filename 
. $ Read Data 


1 e.g. OPEN (UNIT=1 , NAME=FILENAME , - 

t STATUS* ’ OLD * ) 

I e.g. READ (1) data 

Contents of file 98: (abbreviated example) 


I Rotorcraft it 748 -- 
7482DRIVER 
7482DOC 
7482DATA 


ZNEP) : [TRENDS. UH60 
2NEP1 : [TRENDS] 
2NEP2: [DB748 ) 


1 Unique code for rotorcraft 
1 Generic help files 
I rotorcraft data 


1 Rotorcraft t 7<">3 -- 
7032DRIVER 
7032DOC 
7032DAT/ 


ZNEP1: [TRENDS. XV15 
2NEP1: [TRENDS] 
2NEP3 : [DB/03] 


t NEP1: Neptune 1 disk drive 
t NEP3 : Neptune 3 disk drive 
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Access to archived data 
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Additional features 
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Ames databases 
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Analysis 

Analysis programs 
Analysis tools 
Analytical capabilities 
AND search 
ASCII file 
Auto-corre la t ion 
Automatic checks 
Automatic labeling 
Automatic processing 
Automat ic scaling 
Aut omat ic t it les 
Automatic updating 
Availability of time history 
Available informat ion 
Average - 09 c: i 1 la tor y 
Aver age- steady 


4. 2. 3. 3, 6.1.6 
2 . 1.6 

6.1.3 

3 . A . 3 . 1 
A .0 
2 . 1.6 

3.1.1 

2.3 

3 .2 . A 
3 . A 
2.1.6 

3 . A , 3. A. 2, 3 . A . 3 , 5.5 

3 .2, A 

3 . 3 . 2 . 1 

3 . 2 . 1 . A 
3. A. 3.1 
A. 2. 3. 5 

2. 2. 2. 3, 3. 2. 1.2 
A . 0 f A. 2. 3. A 

3. 2. 1.2, 5. 1.3. 6 

3.2, 3 . 2 . 1 . 2 
A. 2. 5, 6.1.6 

data 3.3 

6.1.2 

2. 2. 2.1 f 3.3.1 .1 
2. 2. 2.1, 3. 3. 1.1 


--- B 

Bad data 

Band -edge problem? 

Bell Standard-Lab* 1 tapes 
Brief description of menu items 


A. 2. 3, 5.2 
A. 2.3.1 
A. 2.1 
3.1.1 


Cal cuius operations 
Cal Lin at ions 
CALIBS in menu 
Capabilities of DaTAMAP 
Checking bad data 
Check programs 
Chronology of development 
Coherence funct io i 
Common file structures 
COMPARE in menu 
Comparison with flight test 
Compos i te counters 
Compressor tapes 


3. A. 1.2, app B 

2.1. A.1, 2.3.1, 3.1.1, 6.1.3 

3.1.1. 6.1.3 
3. A. 3.1 

A. 2. 3.1 
A. 2. 3. 5 
app A 
3 . A . 3 . l 

6.1. A. 5 

3.1.1 
3. A. 2.1 

2.3.2 
A. 2. 1 
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2 . 1.5 

6.0 

3 . 3 . 1 1 3 . 3 . 1 . .1 
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Data-region specification 
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DATABASE in menu 
Database management 
Database management menu 
Database manager 
Database selection 
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Database vectoring 
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DATAMAP gateway 
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Data correction 
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Data deletion 

Data derivations 

Lata errors 

Data error checking 


6 . 1 . 4 . 6 , app D 

4 . 2.2 

3 . 2 . 1.5 

3 . 3 . 1.1 

6 . 1,10 

2.3 

6 . 1.2 

3 . 1.1 

2 . 2 . 3 , 4 . 0 , 5 . 2.2 

4 . 1 , 6 . 1.7 

2 . 2 . 3 , 2 . 3 . 2 , 4 . 0 , 4 . 2 . 3 . 1 , 5 . 2 . 2. 2 

2 . 1 . 4.1 

2.3 

5 . 2.4 
app F 

6 . 1 . 4 . 1 

3 . 4 . 3.1 

2 . 1 . 4 . 1 , 3 . 1 . 1 , 3 . 4.3 

3 . 2.3 

6 . 1.3 

4 . 2 . 2 . 3 , 4 . 2 . 2. 6 

4 . 2 . 3. 5 

4 . 2 . 3. 3 

5 . 2 . 2. 2 

4 . 2.4 
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2 . 2 . 3 , 4 . 1 . 1 . 1 , 4 . 2 , 4 . 2 . 3 , 4 . 2 . 3 . 1 , 4 . 2 . 3. 5 
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Data philosophy 
Data quality 
Data rates 
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Data searching 

Data snapshot of test point 

Data spikes 

Data storage 

Data storage decisions 

Data tape formats 

Data types 

Deo ima t ion 

Def ine<J- f unc t ion 

Dp r iva t ive s 

De r ive d counterset 

Derived data 

DERIVED in menu 

Derived items 

Derived parameters for UH60 
Derived parameters for XV15 
Derived pseudo- it en 
Derived time histories 
Desr t i pt ive f M es 
Design considerations 
Despiking data 
Detailed help 
Development history 
Development of TRENDS 
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Digital filter 
Dispersion of filer 
Displaying numerical data 
DISSPLA graphics package 
Documentation 

--- E 

Ease of requesting plots 
Editing plot setups 
Editing the data 
Engineering discip ines 
Engineering interface 
Engineering tests 
Entry errors 
Entry of narrative 
Entry syntax 
Enor checking 

Evaluat ion of formulas 
Examples of TIMEHiST 


6.1.8, 6.1.9 

5.2 

2.2.3, 4.2, 4.2.3, 6.1.9 

2 . 2 . 2. 2 

2. 2. 2. 3, 3.1.2, 3.2.5, 3.3.1, 3. 3. 1.1, 

3. 3. 3.1, 3.4.3 

5.2, 6.1.9 

3.3 

3.2.2 

4. 1.1.1, 4. 2. 3. 2 

4.2.2 

2 . 2 . 2. 2 

4.2.1 

2.2.2, 6. 1.4. 6 

2. 2. 2. 2, 4. 2. 1.1, 4.2.2. 4 

3.1.1 

3. 2. 1.1, 3.4, 3.4.1, 3. 4. 1.1, 3. 4. 1.2 

3.3, 3. 3. 2.1, 5. 1.3. 2 

4.2, 4. 2. 1.1 

3.1.1 
4.2.4 

4. 2. 4. 2 

4 . 2 . 4 . 2 

3.1.1 

3 . 2 . 1 . 4 

5.2. 4.3 
5.0 

4. 2. 3. 2 
2.1.7 
app A 

5.1.3 

3.1.2 

3. 4. 1.5 

6. 1.4. 6 

3.2 

5.6 
2.1.7 


5. 1.3.1 

3. 2. 1.3, 5. 1.3. 6 

2.2.3 

1 . 1.1 
1 . 1.1 

2.2 

2.1 .4.4 

2.2.3 

2. 1.4. 3, 3.1.2, app B 

2.2.3, 4.1. 1.1, 4.2, 4.2.3, 4. 2. 3.1, 4 
6.1.8, 6.1.9 

3.2.1 

3.2.1 
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3.3.2 
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Example of SEARCH 
Example of WORDSCAN 


3 . 3 • 1 . 1 
3. 3. 2.1 
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Features of TRENDS 

1.1.2 

FFT analysis 

3.2.4, 3. 4. 1.2, 3. 4. 1.3 

FILES in menu 

3.1.1, 3.3.3 

File access 
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File structure 
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Filling the database 

2.2.3, 5.2.4. 1 

F.i l tering 

2. 2. 2. 2, 3.4, 3.4.1, 4. 2. 1.1, 4. 2. 2. 4 

Filter syntax 

3. 4. 1.5 

FIND in menu 

3.1.1, 3.3 

Flexibility 

6.1 .4.4 
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3.1.1 

Flight-test database 

2.3.4 

FI ight- test support 

6.1.8 

FLIGHTS. A/C 
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FLIGHTS in menu 

3.1.1, 3.3. 3.3.2 

Flight description 
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Formula evaluation 
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Frequency data plots 
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Frequency distribution 

3.2, 3.2.6 

Func t ions 

3. 2. 1.1, 3. 3. 1.1, app B 

FUNCTION in menu 

3.1.1, 3. 4. 1.1 

Future expansion 
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Help tiles 
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3.1.1 

Ei^lp menus 


3.2. 1.5 
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app E 
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3.0 

Histogram data plots 


3.2.6 

History of development 


1.1, app A 

Hot list 
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I 

— 

Immediate access 


2.1.2 
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3.4.1 

In-line help 


3. 2. 1.5, 5.1 

Incremental development 


5.1.3 

Initial design 


5.1.2 

Initial system software attributes 

5.1.2 

Inline functions 


3 . 4 

Input error checking 


2. 1.4. 4 

Installation of TRENDS 


5 . 6 

Installing data into TRENDS 


4.2 

Instrumentation errors 


6.1.8 

Integer storage 


4. 2. 2. 3 

Integrals 


3. 2. 1.1, 3.4 

Interactive system 


2.1.1 

Interface hardware 


2. 1.4.1 

Interlace to analysis programs 


3. 4. 2.1, 3.4 

Interface to GTRSIM 


3 .4.2.1 

Interface with GTRSIM 
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1 1 eni de f in it ions 


3.1.1, 4.1.2 
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— 

K 

— 

Keyed-access example 


app D 

Keyed access 
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.3 
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1-5 



LOGSCAN in menu 
Low-j^ass filter 


3.1.1, 3.3, 3.3.2 
3, 4.1.5 


--- M 

Maintaining data 
Main menu 
Main menu layout 
Managing a database 
Manuals 

Mathematical functions 
Math model 
Maximum-oscillatory 
Mean value 

Menus for database management 
Menu item 

Menu o rde r 
Min /Max 
Mi n /Max / rev 
Min/Max data 
Min/Max plot t i ng 
Min/Max statistics 

M1NMAX in menu 

MMR data type 
Mnemonic 

Moving-block damping 
Multi family plotting 
Mu 1 1 iple counters 
Mu J \ iple databases 
Multiple TRENDS databases 
MULTIPLT in menu 
Mul t irotoLcraf t 


A . 0 
3 . i 

2. 1.4.1 

5. 2. 4.1 
2.1.7 
6 . 1.2 

2.3.4, 3.1.1, 6.3 

2 . 2 . 2.1 

2.2,2, 3.3.1 

2.2.3 

3.1, 3.1.1, 3.3.2, 4. 1.1.1, 4. 1.2.1, 5.1.1 
5. 1.3. 4 

2. 1.4.1 

2 . 2 . 2.1 

3.1.1, 3.2.6 

2 . 2.2 

3.2.5, 5. 1.3.1 

3.1.2, 3.3.1, 4.2. 1.1, 4. 2. 3. 3, 4.2.4, 

4. 2. 4.1 

3.1.1, 3.1.2, 3.2, 3. 2. 1.5, 3.2.5, 3. 3. 3.1 
3. 4. 1.4, 4.2.4. 3 

3.2.6 

2.3.2, 3.3.2, 3. 4. 2.1, 5.2,4, 5.2.4. 3, 

6 . 1 . 4 . 3 

3. 4. 3.1 
3.2.5 

3.1.1 

1.1.1, 5.2.3 

1.1.1 

3.1.1, 3.1,2, 3.2.5, 3. 3. 3.1 

2.1.3 


Na r rat i ve 

Narrat ive information 
Narrative search 
Needs of users 
NEITHER/ NOR search 
Nongraphic terminals 
Numerical condition search 


On- ] ine analysis 
On-iine help 
Online database 
o p u r c a i disk 
OR search 


- N 

1.1.1, 2. 2. 2. 3, 5. 1.3. 2 

4. 2. 1.3 

2. 1.4.1, 3.3, 3.3.2, 3.3.3 
3.4 

3. 3. 2.1 
3.2 

3.3, 3.3.1, 3.3.3 

- 0 --- 

2. 1.4.5 

2 . 1 . 4. 3 

2.1.2, 5.2.1, 6.2 

5.2.1, 6.2 

3. 3. 2.1 


1-6 



p 


Parameter def.init.icns 

Parameter names 

Parameter statistics 

Path to test data 

Patterned dialog 

Performance benchms rk 

Performance paramet ers 

Performance plot s 

PERFPLOT in menu 

Personalized database 

Plot t ing capabil it :tes 

Plotting generality 

Plot example from DATAMAP gateway 

Plot families 

Plot hardcopy 

Plot Min/Max 

Plot performance items 

Plot setup 

Plot time histories 

PLTHDCPY in menu 

Polynomial regression 

Power of TRENDS 

Prestored formal as 

Presto ted statistics 

Prime data 

Printer plots 

Processing t ime 

Pro ject information 

PROJECT in menu 

Project t it les 

Prompt - response dialogue 

Prompting programs 

Pseudo- flight 


2 . 1.4.1, 3.3.2, 6 . 1.4. 3 

6. 1.4. 2 

3 . 3 . 1 . 1 

2.2 

2. 1.4.1 

6 . 1.2 

3.2.2 

3.2.2 

3.1.1, 3.2, 3.2.2 
5. 1.3.3 

3.2 

6.1.5 

3. 4. 3.1 

3.1.1 

3.1.1 

3.1.1 

3.1.1 

2. 1.4.3, 3.2.2, 3.2.3 

3.1.1, 3.2.1 

3.1.1 

3.2.1, 3. 2. 1.4, 3.4, 3.4.1, 3. 4. 1.4 
3.0 

3. 2. 1.1, app B 

3.2.5 

4.2.2 

3.2, 3.2.6 

4. 2. 1.2 

1.1.1, 2. 1.4.1, 2.1.7, 5. 2. 4. 3 

3.1.1 
5. 1.3.6 

3. 3. 3.1 

4. 2. 1.3 

3.3, 3.3.1, 3. 3. 1.1, 3.3.2, 3. 3. 2.1, 3.3.3, 
5. 1.3. 2, 5. 1.3. 3 


--- Q — 

Quality monitoring, 2* 

QWIKPLOT in menu 3 * 


Raw time histories 
Real-dat a problem ; 
Recalling plot setups 
Recall of Pseudo- £ light s 
Recompiling 
Record overflow 
Reformatting programs 
Regression 
Relat ing narrat ive 
Reliability of data 
Remote users 


3. 2. 1.4 

4. 2. 3. 4 

3. 2. 1.3, 3.2.2, 5. 1.3.6 

3. 3.3.1 

3.4.1 

4.2.6 

4. 2. 1.1 

3. 4. 1.4 

2. 1.4.2 
6.1.9 

6 . 1.2 


1-7 


Report, structure 
Requirements for TRENDS 
Rot or -rev averaging 
Rotor azimuth 


Samp 1 i ng r a te s 
Saving plot setups 
Scanning narrative 
Scanning numerical data 
Scan test -point descriptions 
Screen-managed menu 
Search 

SEARCH in menu 

Series truncation 
Setup heJ p 
SIMULATE in menu 
Simu I at ion 

Simulation interface 
Size of DATAMAP 
Size of GTRSIM 
Size of TRENDS 
Slope s 
Slope check 
Source of narrative 
Spectral analysis 
SPECTRA in menu 
Statistical data plots 
Statistical measures 
Statistics 
Storage capacity 
Storage requirements 
Storing data 
Storing formulas 
Storing time histories 
St rip-chart plot s 
Structured processing 
Structured syntax 
Success template 
Summary files 
Support ing files 
Supporting narrative 
Surface plots 
Symbol t able 
Synch ronization 
S y i 1 1 ax 

Syntax checking 
Syntax for formulas 
Syntax for plot setup 
System design 
System maintenance 


1.2 

2.1 

4 . 2 . 2. 6 

3 . 2 . 1 , 3 . 4 . 1.6 

S --- 

2 . 2 . 2. 2 

3 . 2 . 1.3 

3 . 3.2 

3 . 3.1 

3 . 3.2 

2 . 1 . 4.1 

3 . 3 

3 . 1 . 1 , 3 . 1 . 2 , 3 . 3 , 3 . 3 . 1 , 3 . 3 . 3 , 4 . 1 . 1 . 1 , 

4 . 2 . 4. 3 

4 . 2 . 2. 5 

3 . 2 . 1.5 

3 . 1.1 

2 . 3 . 4 , 3 . 4.2 

2 . 3.4 

5.6 

5.6 

5.6 

4 . 2.4 

4 . 2 . 3 . 1 

3 . 3.2 

3 . 1 . 1 , 3 . 2 . 4 , 3 . 4 . 1 , 3 . 4 . 3 , 4 . 2 . 2. 5 

3 . 1 . 1 , 3 . 2 , 3 . 2 . 4 , 3 . 4 . 1.3 

3 . 2.5 

2 . 2 . 2 , 2 . 2 . 2 . 1 , 3 . 2.5 

2 . 2 . 2 , 3 . 1.1 

4 . 2.2 

5.6 
4.0 

3 . 2 . 1 . 1 , 3 . 4 . 1.1 

3 . 2 . 1 . 4 , 3 . 2.4 

3 . 2.3 
6 . 1.7 

3 . 4.1 

3 . 3.1 

4 . 2 . 3 . 5 , 4 . 2 . 5 , 5 . 2 . 4 . 3 , 6 . 1.6 

2 . 2 . 3 , 4 . 2 . 5 , 5 . 2 . 4 , 5 . 2 . 4 . 3 , 6 . 1.6 

2 . 1 . 4. 2 

3 . 4 . 3 . 1 

6 . 1 . 4. 3 

4 . 2 . 2. 4 

3 . 4 . 1.1 

2 . 1 . 4 . 4 
app B 

3 . 2 . 1 , 3 . 2 . 1.5 

6 . 1.4 
6.3 


1-8 


System readiness 
System response speed 
System speed 


5.2.2. 1 

6 . 1.6 

2.1.5 


— 

T --- 

Table lookups 

3. 4. 1.1, 

TAIL NO in menu 

3.1.1 

Tail number 

4. 1.1.1 

Terminal character! sties 

3.1.1 

TERMINAL in menu 

3.1.1 

Terminal types 

2. 1.4.1 

Test-point descript ion 

2.2.1, 2 
4 . 1 . 1 . 1 , 
5 .2 . 4 . 3 

Test -point index 

2.2, 2.2 

Test conditions 

3.3 

Test point 

2.2.1 

Test results 

3.3 

Text search 

2. 2. 2. 3 

THFJLES .A/C 

5. 2. 4. 3 

Tiitrutor math model 

2.3.4 

Time -code anomalies* 

4. 2. 3. 4 

T ime -history g r oup v 

app C 

Time -tagged data 

6.1.11 

T1MEHIST in menu 

3.1.1, 3 
3. 4. 1.3, 

T i me histories 

2.2.2, 2 

Time history data 

3.2.1, 3 

Time history data types 

3.3.2 

Time history groups: 

2.1 .4.1, 

Time history plotting 

2 . 1 . 4 . 1 , 

Time history transmitting 

3. 2. 1.4 

Time increment 

6.1.11 

Time offset 

6.1.11 

Time shifts 

3.2.1 

TRENDS-user dialogue 

3.1.2 

TRENDS acronym 

1 . 1 

TRENDS concept 

2 . 1 

TRENDS databases 

2 . 2 

TRENDS design / development 

5.0 

TRENDS deve lopment philosophy 

5.1 

TRENDS features 

1.1.2 

TRENDS overview 

2.0 

TRENDS software 

5.6, app 

TRENDX 

5.1.4 

Trig functions 

3 . 4 . 1 . 1 



U --- 

UH60 database 

2.3.2 

UH60 database management menu 

4.1.2 

UH60 statistics 

3.2.5 

Unique aspects of databases 

2.3 


app B 


2.2.3* 3.3* 3.3.2, 3. 3. 2.1* 3. 3. 3.1, 
4. 1.2.1* 4. 2. 1.3, 4. 2. 2.1, 5. 1.3.6* 

1 


2, 3.2.1, 3.2. 1.5, 3.2.4* 3. 3. 3.1, 
3. 4. 1.4, 3. 4. 1.5, 3. 4. 1.6, 5. 1.3. 4 

2 . 2.2 
4 . 1 

3.1.1, 4 . 2 . 2 . 2 
3.2.3, 5. 1.3. 4 


E 


1-9 



User’s database 


5 . 1 . 3 . 3 

User’s directory 


5. 1,3, 3 

User’s manual 


5,1.1 

User- created files 


3.1.1 

Use r-def ined tunc t ions 


5. 1.3. 4 

User-driven development 


5.1.3 

User-friendliness 


2.1.4 f 5.1,3, 5.3 

User-friendly 


3.0, 5.1, 5. 1.3.1 

User-friendly autoplot setup 


5. 1.3. 6 

User-generated functions 


5. 1.3. 5 

User- sot tware exclusion 


2.1.6 

User-specified titles 


3. 2. 1.2 

Users 


1 . 1.1 

User acceptance 


5.2.1, 6.1.6 

User confidence 


4. 2. 3. 3, 6.1.9 

User feedback 


5.4, 6.1.11 

User help 


2.1.7 

User impact on development 


6.1.1 

User requirements 


5.4 

— 

V 

— 

Val id i t y checks 


4.0 

VIEW in menu 


3.1.1, 3.1.2 

— 

w 

— 

Wind tunnel da t abases 


2.3.3 

WORDSCAN in menu 


3.1.1, 3.3, 3.3.2, 
4. 1.2.1 

WORM 


5.2.1, 6.2 



X 

— 

XV15 database 


2.3.1 

XV15 database management menu 


4.1.1 

XV 15 statistics 


3.2.5 


1-10 



Report Documentation Page 

Spaca Admimstt ah on 

1 Report No. 2 Government Accession No. 

NASA TM-101025 

3. Recipient's Catalog No. 

4. Title and Subtitle 

TRENDS: The Aeronautical Post-Test 
Database Management System 

5. Report Date 

January 1990 

6. Performing Organization Code 

7. Author(s) 

W. S. Bjorkman (Analytical Mechanics Associates, Inc., 
Mountain View, California) ar d M. J. Bondi 

8. Performing Organization Report No. 

A-88225 

10. Work Unit No 

505-61-51 

9. Performing Organization Name and Address 

Ames Research Center 
Moffett Field, CA 94035-1000 

1 1 . Contract or Grant No 

13. Type of Report and Period Covered 

Technical Memorandum 

1 2. Sponsoring Agency Name and Address 

National Aeronautics and Spa:e Administration 
Washington, DC 20546-0001 

14. Sponsoring Agency Code 

15. Supplementary Notes 


Point of Contact: M. J. Bondi, Ames Research Center, MS 237-5, Moffett Field, CA 94035-1000 
(415) 604-6311 orFTS 464-6341 


16. Abstract 


TRENDS, an engineering test database operating system developed by NASA to support rotorcraft 
flight tests, is described. Capa >ilities and characteristics of the system are presented, with examples of its 
use in recalling and analyzing rotorcraft flight-test data from a TRENDS database. The importance of 
system user-friendliness in gaining users’ acceptance is stressed, as is the importance of integrating 
supporting narrative data with numerical data in engineering-test databases. 

Considerations relevant to the creation and maintenance of flight-test databases are discussed and 
TRENDS’ solutions to datatose management problems are described. 

Requirements, constraint:;, and other considerations which led to the system's configuration are 
discussed and some of the lessons learned during TRENDS’ development are presented. Potential 
applications of TRENDS to a wide range of aeronautical and other engineering tests are pointed out. 


Key Words (Suggested by Author(s)) 

Flight test 
Rotorcraft 

Engineering-test database 
Database management 

Security Classif (ot this report) 

Unclassified 


18. Distribution Statement 

Unclassified-Unlimited 

Subject Category - 09 


20. Security Classif. (of this page) 

Unclassified 


21. No. of Pages 

131 


22. Price 


A07 


For sale by the National Technical Information Service, Springfield. Virginia 22161 




